|
From: Remi D. <re...@ch...> - 2003-03-18 11:55:14
|
> Okay gang, here's the status.
>
> 1. updated files checked in:
> file new version
> ------------ -----------
> cherrypy.py 1.14
> src/httpTools.py 1.3
> src/httpServer.py 1.3
> src/parseConfigFile.py 1.2
>
> Changes to all but httpTools.py are modest, mostly around the new config
> parameter.
>
> 2. httpTools.py is mostly functional, but not complete. Outstanding:
> a. the StringIO thing we've been discussing to fork _rfile for two
> different uses. I couldn't find any examples and couldn't figure it out
> with a little experimentation, so I swallowed my pride and am deferring
> to more experienced hands. I deleted my StringIO mess, so you can start
> clean.
>
> b. I'm pretty sure I'm not properly handling the error case at line 65,
> in which someone has requested an existing non-xmlrpc method via xmlrpc.
> I'm raising an error, but not doing whatever I need to do to send it
> back properly to the client. On line 66, I make a case for skipping the
> error and just redefining request.path to something so obscure as to
> never come up, and letting the normal not-a-method handling take over.
> Of course, that can't be tested until (a) is working.
>
> c. The case in which we get an error by trying to run xmlrpclib.loads()
> on something that isn't an xmlrpc request isn't being caught by name.
> The error thrown is ExpatError, but when I try to except just for that,
> I get an error saying that ExpatError isn't defined. I'm sure it's
> something simple (and obvious), but I'm so frustrated by (a) at this
> point, I'm not thinking clearly.
>
> 3. I created some test tools and checked them into a new dir, test.
> (I'll rm the dir when we're done with this).
> a. Main.cpy has xmlrpc, web, and hidden methods for hitting against.
> b. MainServer.cfg...well, you know.
> c. xmlrpctest.py has 7 tests, of which 6 pass (1-5, 7). Test 6 is hung
> up on item 2a, above. Running the script is very straightforward:
> python xmlrpctest.py # runs all tests
> python xmlrpctest.py N # runs test N [1-7]
Okay, I've commited my changed. Here are my comments:
- request.headerMap['content-type'] will raise an error if the header has no
content-type. I've changed it to request.headerMap.get('content-type','')
- to check if a dictionnary has a given key, you shouldn't use:
if key in myDict.keys()
but
if myDict.has_key(key)
The former will first build a list with all the keys and then perform a list
lookup, which is much slower than a direct dictionnary key lookup.
- I've implemented Joe's solution (using StringIO)
- It looks like xmlrpclib.loads may raise several errors. So instead of
figuring out the complete list of possible errors, I've put a "generic"
except statement, just around this call. It then raises a single error,
which is caught later.
- I've moved the checks on class/method existence and correct type to
_handleRequest so the error is correctly sent back to the client.
- I've added an additional check: if someone tries to request and XML-RPC
method from a browser, this will be trapped.
- I've also updated cherrypy.py so you can now define a whole CherryClass as
xmlrpc:
CherryClass MyClass xmlrpc:
view:
def add(self, a, b):
return a+B
- Right now, if you subclass this class, the subclass won't inherit the
XML-RPC characteristics. I think it's not a very big deal so we can leave it
like this for now.
- I've also added a check in parseConfigFile.py, to check that users only
put "xmlrpc" or "web" in typeOfRequests. This will trapp errors like putting
"xmlRpc" in it (it actually happened to me :-)
- I didn't see your test scripts in the CVS tree so I wasn't able to run
them.
- The next step will be to update the HowTo (if you feel like doing it, go
for it; otherwise, I'll take care of it :-)
Best,
Remi.
|