cherrypy-devel — For the development of CherryPy

[Cherrypy-devel] Changes in getModuleLines (cherrypy.py)

[Chema C. <py...@ch...>]

Because I had some problems with the environment variable CHERRYPY_HOME
under windows, I had had to look into the code. I see that paths are
codified thinking in unix. It would be better to use the os.path module
to join paths and do some tests. After working with the code, this is my
refactorized code:

(--------------------------)
def getModuleLines(includeDirList, fileName, extension):
	fileNameBase,fileNameExtension = os.path.splitext(fileName)
	if fileNameExtension!=extension:
		fileName+=extension
	if not os.path.isabs(fileName):
		# Relative path search
		for dirName in includeDirList:
			fileRelName=os.path.join(dirName,fileName)
			if os.path.exists(fileRelName):
				fileName=fileRelName
				break
		else:
			raise 'CherryError: Cannot find file %s'%`fileName`
	data=file(fileName,'r').read()
	return data.replace(' '*whiteSpace,'\t').splitlines()
(------------------------------)

I think that all conversions between Mac/Win to Unix textline can be do
better with the string.splitlines

Also, an optimization can be done some lines before:

(------------------------------)
# Parse arguments
includeDirList=['.', '../lib', '../src']
if os.environ.has_key('CHERRYPY_HOME'):
	home=os.environ['CHERRYPY_HOME']
	includeDirList.append(os.path.join(home,'lib'))
	includeDirList.append(os.path.join(home,'src'))
includeDirList=filter(os.path.exists,includeDirList)
(------------------------------)

The filtered "includeDirList" only contains right paths.

Remi, if you like to include me as developer, I would do theses changes
myself in the CVS. My username at sourceforge is "chemacortes".

Ah, my problem with windows. I had wrote the path with quotation marks,
like CHERRYPY_HOME="C:\work\cherrypy" . It would be a good idea to check
this as:

if home[0] in ['"',"'"]: home=home[1:-1]

--
"Make free software, not war"

RE: [Cherrypy-devel] xml-rpc works; howto changes

[Remi D. <re...@ch...>]

> I've run through the new xmlrpc changes and everything seems to work
> great!

Great.

> Here's are some copy changes for the HowTo. I tried to stick to your
> style as much as possible. Give me your comments and I'll be happy to
> mark this up in HTML.

I think it's fine the way it is. I'll include it in the next release. Don't
worry about converting it to HTML, I'll take care of it. I actually use
Latex to write documentation (which is then automatically converted into
HTML).

[Cherrypy-devel] xml-rpc works; howto changes

[Steven N. <ste...@th...>]

I've run through the new xmlrpc changes and everything seems to work
great! The StringIO stuff makes a lot of sense, now that I can see an
example. Thanks again for cleaning up after me. :)


Here's are some copy changes for the HowTo. I tried to stick to your
style as much as possible. Give me your comments and I'll be happy to
mark this up in HTML.

------


13. How to create an XML-RPC server with CherryPy

13.1 Introduction
Writing an XML-RPC service with CherryPy is very easy. It works very
much the same way as a regular web service. It is base on the xmlrpclib
module. This module is included with Python-2.2 and higher, but if you
use a lower version, you'll have to download it from
http://www.pythonware.com. 

All you have to do is add the keyword xmlrpc after the definition of the
mask or view, and before the colon. Now, that view or mask will be
available to XML-RPC requests. 

13.2 Basic Example
Let's take an example. Just create a file called testXmlRpc.cpy
containing the following code: 

CherryClass Root:
view:
    def add(self, a, b, c) xmlrpc:
        # Return the sum of three numbers
        return a+b+c

CherryClass Xml_rpc:
view:
    def reverse(self, label) xmlrpc:
        # Reverse the characters of a string
        newStr=''
        for i in range(len(label)-1,-1,-1):
            newStr+=label[i]
        return newStr


Also, create a configuration file (textXmlRpcServer.cfg) to tell the
server to accept XML-RPC requests: 

[server]
typeOfRequests=xmlRpc,web

Compile the source file and start the server: you have an XMl-RPC server
running. 

Now let's write a client. Just create a file called testXmlRpcClient.py
containing the following code: 

import xmlrpclib
testsvr = xmlrpclib.Server("http://localhost:8000")
print testsvr.add(1,2,3)
print testsvr.xml.rpc.reverse("I love cherry pie")


Run the client and you should see: 

[remi@serveur]$ python xmlrpcTestClient.py
6
eip yrrehc evol I
[remi@serveur]$


13.3 Multiple Servers

CherryPy lets you define your XML-RPC server URIs any way you want. In
our example client above, we used:
testsvr = xmlrpclib.Server("http://localhost:8000")
print testsvr.xml.rpc.reverse("I love cherry pie")

However, either of the following would work just as well.

testsvr = xmlrpclib.Server("http://localhost:8000/xml")
print testsvr.rpc.reverse("I love cherry pie")

testsvr = xmlrpclib.Server("http://localhost:8000/xml/rpc")
print testsvr.reverse("I love cherry pie")

Note that in these two examples, the add view in the Root CherryClass
would not be available to the XML-RPC client. This gives you the
flexibility to define your XML-RPC APIs to make different methods
available at different URIs.

[Cherrypy-devel] Re: [Cherrypy-users] Help to run cherrypy under JVM

[steve @ W. <st...@wa...>]

The Nav4 engine underneath Waypath is Java, served with Jetty, so
something like this would be an option for Waypath. I haven't played
with Jython yet. What would be the advantage of running it this way?

On Thu, 2003-03-20 at 08:08, Alex Reid wrote:
> Hi
>=20
> If it's possible to run CherryPy under Jython, do you think it'd be much
> work to run a CherryPy application as a servlet from within a container l=
ike
> Tomcat? Perhaps by extending JythonServlet....?
>=20
> I've used JythonServlet in the past and it works very well indeed .. grea=
t
> to have the entire servlet API available from within Python :)
>=20
> May investigate this when I get time....
>=20
> Alex
>=20
> ----- Original Message -----
> From: "Remi Delon" <re...@ch...>
> To: "CherryPy Devel" <che...@li...>
> Sent: Thursday, March 20, 2003 4:01 PM
> Subject: RE: [Cherrypy-users] Help to run cherrypy under JVM
>=20
>=20
> > Hello Chema,
> >
> > I had never tried to run CherryPy under jython before ...
> >
> > I just tried it and I got the same error as you probably did (no
> > "_fileobject" attribute in the "socket" module).
> > There is only a small part of the code that uses this, and it's only
> needed
> > for SSL socket support.
> > So I added a special test in the source code that says to use this code
> only
> > if we're not using jython...
> >
> > And it worked !
> >
> > I commited my changes in CVS so you can get the latest code from CVS an=
d
> it
> > should fix your problem.
> >
> > Instructions on how to get the CVS files are available on the CherryPy
> > website.
> >
> > Regards.
> >
> > Remi.
> >
> >
> > > I want to run my server under JVM using jython, but I only get an
> > > error with the
> > > sockets. will that be possible?
> > >
> > >
> > > --
> > > Chema Cort=E9s
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Tablet PC.
> > Does your code think in ink? You could win a Tablet PC.
> > Get a free Tablet PC hat just for playing. What are you waiting for?
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> > _______________________________________________
> > Cherrypy-users mailing list
> > Che...@li...
> > https://lists.sourceforge.net/lists/listinfo/cherrypy-users
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Tablet PC. =20
> Does your code think in ink? You could win a Tablet PC.=20
> Get a free Tablet PC hat just for playing. What are you waiting for?=20
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> Cherrypy-users mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/cherrypy-users
>=20

RE: [Cherrypy-devel] new checkins, need help

[Steven N. <ste...@th...>]

Sorry to drop off for a few days...my work caught up with me. I haven't
had a chance to try this out yet, but should be able to this evening.
(It's morning here now.)

Remi, thanks for finishing this up. I'm not sure I saved you much time
in the end, but at least I learned something. :)

I must have forgotten to commit the test dir. If I run into problems or
the tests don't pass, I'll commit them for real. Otherwise, I'll report
back with good news. I'll look at the HowTo, as well.

Steve


On Tue, 2003-03-18 at 03:55, Remi Delon wrote:
> > 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.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Does your code think in ink? 
> You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
> What are you waiting for?
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> Cherrypy-devel mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/cherrypy-devel
> 

RE: [Cherrypy-devel] new checkins, need help

[Remi D. <re...@ch...>]

> 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.

[Cherrypy-devel] new checkins, need help

[Steven N. <ste...@th...>]

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]

RE: [Cherrypy-devel] Followup--possible kludge

[Remi D. <re...@ch...>]

> Right now, the assignment:
> self.rfile=CherryFileObject(self.connection, 'rb', self.rbufsize)
> takes place in the setup method of CherryHTTPRequestHandler.

You don't have to change that ...
Just change the code in parsePostData (use the approach that Joe suggested):
read the request body and put it in a StringIO object at the beginning of
the function. The advantage is that you can then pass this StringIO object
to the FieldStorage method, since StringIO works like a file object.

> If I check in my changes so far, do you have time to take a look at
> this?

Sure.


Remi.

RE: [Cherrypy-devel] Followup--possible kludge

[Steven N. <ste...@th...>]

Right now, the assignment:
self.rfile=CherryFileObject(self.connection, 'rb', self.rbufsize)
takes place in the setup method of CherryHTTPRequestHandler.

I don't have any idea how to wrap that in a try: block linked to the
xmlrpc processing without rewriting a whole bunch of stuff. I'm
confident it can be done more simply, but I just can't see it yet.

If I check in my changes so far, do you have time to take a look at
this?

On Mon, 2003-03-17 at 06:22, Remi Delon wrote:
> > Because xml-rpc comes over HTTP, it's difficult to make assumptions...I
> > think. I think we should be able to count on an xml-rpc client sending
> > 'text/xml' as the content-type. The next question would be, can we count
> > on web browsers to never sent 'text/xml' as the content-type? I'm
> > willing to make that assumption. :)
> 
> Well, I hadn't noticed that XML-RPC clients were sending content-type in the
> request.
> 
> I think that your first assumtion is quite safe.
> The spec says:
> "A User-Agent and Host must be specified.
> The Content-Type is text/xml.
> The Content-Length must be specified and must be correct."
> 
> So even though it doesn't use the word "must" for "Content-Type", I think we
> can reasonably assume the the Content-Type will always be there and it will
> always contain "text/xml".
> 
> 
> But your second assumption (that other clients never send a Content-Type
> with "text/xml") seems quite dangerous. Besides, remember that CherryPy
> could potentially support other protocols in the future, which may also be
> using "text/xml" for the content-type ...
> 
> So I think that we should stick to the previous method (try to parse the
> request body as an XML-RPC request and handle it as a regular web request if
> it fails).
> 
> Remi.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Cherrypy-devel mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/cherrypy-devel
> 

RE: [Cherrypy-devel] Followup--possible kludge

[Remi D. <re...@ch...>]

> Because xml-rpc comes over HTTP, it's difficult to make assumptions...I
> think. I think we should be able to count on an xml-rpc client sending
> 'text/xml' as the content-type. The next question would be, can we count
> on web browsers to never sent 'text/xml' as the content-type? I'm
> willing to make that assumption. :)

Well, I hadn't noticed that XML-RPC clients were sending content-type in the
request.

I think that your first assumtion is quite safe.
The spec says:
"A User-Agent and Host must be specified.
The Content-Type is text/xml.
The Content-Length must be specified and must be correct."

So even though it doesn't use the word "must" for "Content-Type", I think we
can reasonably assume the the Content-Type will always be there and it will
always contain "text/xml".


But your second assumption (that other clients never send a Content-Type
with "text/xml") seems quite dangerous. Besides, remember that CherryPy
could potentially support other protocols in the future, which may also be
using "text/xml" for the content-type ...

So I think that we should stick to the previous method (try to parse the
request body as an XML-RPC request and handle it as a regular web request if
it fails).

Remi.

RE: [Cherrypy-devel] hung up

[Remi D. <re...@ch...>]

> >
> > What I think you should do is rethink the code so that it
> > does something like this:
> >
> > import StringIO
> > theData = _rfile.read()
> > try:
> >   _rfile = StringIO.StringIO(theData)
> >   _paramTuple,_thisXmlRpcMethod=xmlrpclib.loads(_data)
> >   ...handle it as an XMLRPC request...
> > except SomeUsefulException:
> >   _rfile = StringIO.StringIO(theData)
> >   _forms=cgi.FieldStorage(fp=_rfile, headers=request.headerMap,
> >     environ={'REQUEST_METHOD':'POST'}, keep_blank_values=1)
> >   ...handle it as a cgi request...
> >
> > This will work provided nothing inside the code that handles
> > the request tries to do anything with _rfile except read data
> > out of it.
>
> That makes sense. I'm not sure how much of a major surgery it would take
> to get that done. I think I'm willing to try, but I'd bet Remi has
> something to say.

I think that Joe's solution is good. It only requires to change a few lines
of code ...

Re: [Cherrypy-devel] Followup--possible kludge

[Steven N. <ste...@th...>]

Because xml-rpc comes over HTTP, it's difficult to make assumptions...I
think. I think we should be able to count on an xml-rpc client sending
'text/xml' as the content-type. The next question would be, can we count
on web browsers to never sent 'text/xml' as the content-type? I'm
willing to make that assumption. :)

On Sun, 2003-03-16 at 18:10, Joe wrote:
> Steven Nieker <ste...@th...> writes:
> 
> > It turns out that content-type does come in with the request, and that
> > xmlrpc content-type should be 'text/xml' (which is required by the spec,
> > as well).
> > 
> > So, a simple kludge to avoid the pending problem about modifying _rfile
> > in the xmlrpc code and then trying to use it again in the web code if it
> > turns out that the request is _not_ for xmlrpc...is to make the xmlrpc
> > code conditional on the content-type being 'text/xml.'
> > 
> > This seems to get me around the problem but it's hardly foolproof. It
> > also requires some creative error handling, with which I'll need some
> > help. On the other hand, it shouldn't pose any more flaws than breaking
> > poorly constructed clients, and it actually improves the state of xmlrpc
> > handling from the 0.8 release.
> > 
> > What do you think?
> 
> This is along the lines of the ideal solution. There ought to
> be some way to tell if a request is XMLRPC without reading the
> post data. Surely there's got to be something in the XMLRPC
> spec that allows you to make that decision reliably?
> 
> -- Joe Knapka
> [Who has no clue about XMLRPC, but can at least post to the list now.]
> 
> 

[Cherrypy-devel] Followup--possible kludge

[Steven N. <ste...@th...>]

It turns out that content-type does come in with the request, and that
xmlrpc content-type should be 'text/xml' (which is required by the spec,
as well).

So, a simple kludge to avoid the pending problem about modifying _rfile
in the xmlrpc code and then trying to use it again in the web code if it
turns out that the request is _not_ for xmlrpc...is to make the xmlrpc
code conditional on the content-type being 'text/xml.'

This seems to get me around the problem but it's hardly foolproof. It
also requires some creative error handling, with which I'll need some
help. On the other hand, it shouldn't pose any more flaws than breaking
poorly constructed clients, and it actually improves the state of xmlrpc
handling from the 0.8 release.

What do you think?

Re: [Cherrypy-devel] hung up

[steve @ W. <st...@wa...>]

> So essentially, this code says,
> 
> Try doing something irretrievably destructive to _rfile;
> if that works, goodie!
> Otherwise, try doing something that expects _rfile to be in
> its original state.

Yes, that seems to be the case. 

> 
> And it looks like you have the same problem if you try to read
> stuff in the opposite order.

Yes, verified. I've also tried duplicating _rfile:

  _xfile = _rfile
  do something to _file
  do something to _rfile

but the two pointers seem to modify the same object. (In case you can't
tell, my Python knowledge is experiential.

> 
> What I think you should do is rethink the code so that it
> does something like this:
> 
> import StringIO
> theData = _rfile.read()
> try:
>   _rfile = StringIO.StringIO(theData)
>   _paramTuple,_thisXmlRpcMethod=xmlrpclib.loads(_data)
>   ...handle it as an XMLRPC request...
> except SomeUsefulException:
>   _rfile = StringIO.StringIO(theData)
>   _forms=cgi.FieldStorage(fp=_rfile, headers=request.headerMap,
>     environ={'REQUEST_METHOD':'POST'}, keep_blank_values=1)
>   ...handle it as a cgi request...
> 
> This will work provided nothing inside the code that handles
> the request tries to do anything with _rfile except read data
> out of it.

That makes sense. I'm not sure how much of a major surgery it would take
to get that done. I think I'm willing to try, but I'd bet Remi has
something to say.

> 
> Cheers,
> 
> -- Joe Knapka
> [Who gets cherrypy-devel messages, but can't post to the list
> for some reason.]

Hey, you made it!

Re: [Cherrypy-devel] hung up

[Joe <jk...@ea...>]

"steve @ Waypath" <st...@wa...> writes:

> Remi,
> 
> I've spent several hours trying to get around this problem, but I'm
> pretty stuck.
> 
> Here's an abridged _parsePostData():
> 
> def _parsePostData(_rfile):
>  if 'xmlRpc' in _typeOfRequests:
>     try:
>       _data=_rfile.read(int(request.headerMap["content-length"]))
>       _paramTuple,_thisXmlRpcMethod=xmlrpclib.loads(_data)
> 
>     [various tests to set request.isXmlRpc]          
>  
>  if request.isXmlRpc:
>     [ do something] 
> 
>  else:
>     # It's a normal browser call
>     _forms=cgi.FieldStorage(fp=_rfile, headers=request.headerMap,
> 	environ={'REQUEST_METHOD':'POST'}, keep_blank_values=1)
>     [process _forms]
> 
> 
> What I'm finding is that the line
>       _data=_rfile.read(int(request.headerMap["content-length"]))
> conflicts with the line 
>     _forms=cgi.FieldStorage(fp=_rfile, headers=request.headerMap,
> 	environ={'REQUEST_METHOD':'POST'}, keep_blank_values=1)
> whenever my request is an HTML POST request.
> 
> If I set typeOfRequests in the config file to only process web (and not
> xmlRpc), then everything runs just fine. However, if typeOfRequests is
> set to both xmlRpc and web, then, an HTML POST request
>  - causes an error in the _data... line, which gets trapped successfully
>  - hangs indefinitely when it gets to the _forms... line. 
> 
> It seems that the action on _rfile in the first line prevents proper
> action on _rfile in the second line, even though the first line's was
> trapped.
> 
> My ability to handle this severely hampered by the fact that I don't
> know anything about sockets or the part of Python that is dealing with
> _rfile. Do you know a way to "reset" _rfile when I trap the error in the
> _data line?

So essentially, this code says,

Try doing something irretrievably destructive to _rfile;
if that works, goodie!
Otherwise, try doing something that expects _rfile to be in
its original state.

And it looks like you have the same problem if you try to read
stuff in the opposite order.

What I think you should do is rethink the code so that it
does something like this:

import StringIO
theData = _rfile.read()
try:
  _rfile = StringIO.StringIO(theData)
  _paramTuple,_thisXmlRpcMethod=xmlrpclib.loads(_data)
  ...handle it as an XMLRPC request...
except SomeUsefulException:
  _rfile = StringIO.StringIO(theData)
  _forms=cgi.FieldStorage(fp=_rfile, headers=request.headerMap,
    environ={'REQUEST_METHOD':'POST'}, keep_blank_values=1)
  ...handle it as a cgi request...

This will work provided nothing inside the code that handles
the request tries to do anything with _rfile except read data
out of it.

Cheers,

-- Joe Knapka
[Who gets cherrypy-devel messages, but can't post to the list
for some reason.]

[Cherrypy-devel] hung up

[steve @ W. <st...@wa...>]

Remi,

I've spent several hours trying to get around this problem, but I'm
pretty stuck.

Here's an abridged _parsePostData():

def _parsePostData(_rfile):
 if 'xmlRpc' in _typeOfRequests:
    try:
      _data=_rfile.read(int(request.headerMap["content-length"]))
      _paramTuple,_thisXmlRpcMethod=xmlrpclib.loads(_data)

    [various tests to set request.isXmlRpc]          
 
 if request.isXmlRpc:
    [ do something] 

 else:
    # It's a normal browser call
    _forms=cgi.FieldStorage(fp=_rfile, headers=request.headerMap,
	environ={'REQUEST_METHOD':'POST'}, keep_blank_values=1)
    [process _forms]


What I'm finding is that the line
      _data=_rfile.read(int(request.headerMap["content-length"]))
conflicts with the line 
    _forms=cgi.FieldStorage(fp=_rfile, headers=request.headerMap,
	environ={'REQUEST_METHOD':'POST'}, keep_blank_values=1)
whenever my request is an HTML POST request.

If I set typeOfRequests in the config file to only process web (and not
xmlRpc), then everything runs just fine. However, if typeOfRequests is
set to both xmlRpc and web, then, an HTML POST request
 - causes an error in the _data... line, which gets trapped successfully
 - hangs indefinitely when it gets to the _forms... line. 

It seems that the action on _rfile in the first line prevents proper
action on _rfile in the second line, even though the first line's was
trapped.

My ability to handle this severely hampered by the fact that I don't
know anything about sockets or the part of Python that is dealing with
_rfile. Do you know a way to "reset" _rfile when I trap the error in the
_data line?

This may help. When the _forms... line hangs, if I hit ctl-C, I get this
error in the console serving CherryPy:

Exception happened during processing of request from ('192.168.1.1',
54827)
Traceback (most recent call last):
  File "/usr/local/lib/python2.2/SocketServer.py", line 221, in
handle_request
    self.process_request(request, client_address)
  File "/usr/local/lib/python2.2/SocketServer.py", line 240, in
process_request
    self.finish_request(request, client_address)
  File "/usr/local/lib/python2.2/SocketServer.py", line 253, in
finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python2.2/SocketServer.py", line 514, in __init__
    self.handle()
  File "/usr/local/lib/python2.2/BaseHTTPServer.py", line 266, in handle
    method()
  File "MainServer.py", line 615, in do_POST
    _doRequest(self.wfile)
  File "MainServer.py", line 418, in _doRequest
    _wfile.write('HTTP/1.1 200\r\n')
  File "/usr/local/lib/python2.2/socket.py", line 197, in write
    self.flush()
  File "MainServer.py", line 657, in flush
    self._sock.sendall(self._wbuf)
error: (32, 'Broken pipe')
----------------------------------------
Exception socket.error: (9, 'Bad file descriptor') in <bound method
CherryFileObject.__del__ of <__main__.CherryFileObject instance at
0x81f861c>> ignored

Thanks,
Steve

RE: [Cherrypy-devel] RE: new files attached

[Steven N. <ste...@th...>]

> 
> > > - When trying to parse the request body, we should probably
> > make a special
> > > case when there is no body (content-length==0) because, again, this case
> > > will probably happend quite often.
> >
> > I'm not sure I get this. I see where content-length gets evaluated in
> > _parsePostData, but I'm not sure what an appropriate response should be
> > if it's ==0.
> 
> Well, if content-length is 0, it just means that there is no request body so
> it cannot be an XML-RPC call. No need to call xmlrpclib.loads()
> Also, using "except:" without specifying any exception is not a very good
> idea. You should see what exception is raised when trying to parse a request
> body that's not an XML-RPC call and only catch *this* excpetion.
> 
Got it.


> > Speaking of special cases...back to the problem of telling xmlrpc
> > requests from web requests:
> >
> > The code I sent you last round works pretty well if the client reqeusts
> > something that's there, but I'm having a lot of trouble trapping
> > problems when the client requests, via xmlrpc, something that either
> > isn't there or that isn't tagged xmlrpc.
> 
> Well, if the corresponding CherryClass/method doesn't exists, then the
> regular error should be displayed (because the CherryClass/method won't be
> in maskAndViewMap at all).
> If the corresponding CherryClass/method isn't tagged xmlrpc, then you should
> take care of returning the error (for instance: raise 'CherryError: method
> "%s" of CherryClass "%s" is not and xmlrpc method').
> 
> So, in _parsePostData, you should use the following algorithm:
> 
> request.isXmlRpc=0
> if 'xmlrpc' in _typeOfRequests:
>     try:
>         parse request.body as an XML-RPC request
>         request.isXmlRpc=1
>         compute corresponding CherryClass/method names
>         if CherryClass/method not in xmlrpcMaskAndViewMap:
>             if CherryClass/method in maskAndViewMap:
>                 # The method exists, but isn't tagged xmlrpc
>                 raise 'CherryError: method "%s" of CherryClass "%s" is not
> and xmlrpc method'
>             else:
>                 # The method doesn't exist at all
>                 # Nothing to do: it will be trapped later by the regular
> maskAndViewMap check
>                 pass
>         else:
>             # Everything is ok: the method exists and is tagged xmlrpc
>             # Nothing to do
>             pass
>     except "parsing failed":
>         # The parsing failed: it's not an XML-RPC request
>         request.isXmlRpc=0
> if request.isXmlRpc=0:
>     # it's a normal browser call
> 

Yes, of course, check against maskAndViewMap! It seems so obvious now.
I'll give that a try. Thanks.

RE: [Cherrypy-devel] RE: new files attached

[Remi D. <re...@ch...>]

> > Weird, because I added you as a develeoper and the SourceForge
> doc says "At
> > this time, all developers have write access to the CVS Repository and to
> > your group directory (web site). There are plans to make these
> permissions
> > optional as well. "
>
> Operator error. I've got it worked out now.

Good !

> > - When trying to parse the request body, we should probably
> make a special
> > case when there is no body (content-length==0) because, again, this case
> > will probably happend quite often.
>
> I'm not sure I get this. I see where content-length gets evaluated in
> _parsePostData, but I'm not sure what an appropriate response should be
> if it's ==0.

Well, if content-length is 0, it just means that there is no request body so
it cannot be an XML-RPC call. No need to call xmlrpclib.loads()
Also, using "except:" without specifying any exception is not a very good
idea. You should see what exception is raised when trying to parse a request
body that's not an XML-RPC call and only catch *this* excpetion.


> Speaking of special cases...back to the problem of telling xmlrpc
> requests from web requests:
>
> The code I sent you last round works pretty well if the client reqeusts
> something that's there, but I'm having a lot of trouble trapping
> problems when the client requests, via xmlrpc, something that either
> isn't there or that isn't tagged xmlrpc.

Well, if the corresponding CherryClass/method doesn't exists, then the
regular error should be displayed (because the CherryClass/method won't be
in maskAndViewMap at all).
If the corresponding CherryClass/method isn't tagged xmlrpc, then you should
take care of returning the error (for instance: raise 'CherryError: method
"%s" of CherryClass "%s" is not and xmlrpc method').

So, in _parsePostData, you should use the following algorithm:

request.isXmlRpc=0
if 'xmlrpc' in _typeOfRequests:
    try:
        parse request.body as an XML-RPC request
        request.isXmlRpc=1
        compute corresponding CherryClass/method names
        if CherryClass/method not in xmlrpcMaskAndViewMap:
            if CherryClass/method in maskAndViewMap:
                # The method exists, but isn't tagged xmlrpc
                raise 'CherryError: method "%s" of CherryClass "%s" is not
and xmlrpc method'
            else:
                # The method doesn't exist at all
                # Nothing to do: it will be trapped later by the regular
maskAndViewMap check
                pass
        else:
            # Everything is ok: the method exists and is tagged xmlrpc
            # Nothing to do
            pass
    except "parsing failed":
        # The parsing failed: it's not an XML-RPC request
        request.isXmlRpc=0
if request.isXmlRpc=0:
    # it's a normal browser call

> I know the goal is to keep things simple. Because xmlrpc requests get
> treated as POST requests, the need to distinguish between the two only
> happens in the _parsePostData code. Would it be too simple to make the
> test content-type==text/xml?
>
> The assumption would be that xml-rpc request would always be text/xml
> and HTML POST requests would never be text/xml. If we can make that
> assumption, I can move the test higher up in the xmlrpc processing and
> we can go back to having both 'xmlRpc' and 'web' as our default
> typeOfReqeusts. More importantly, I can code something that traps
> errors.

The content-type applies to the response, not the request. Besides, a
regular CherryPy mask can return some XML data as well.

Regards.

Remi.

Re: [Cherrypy-devel] RE: new files attached

[Steven N. <ste...@th...>]

On Wed, 2003-03-12 at 01:14, Remi Delon wrote:
> > It turns out I don't have write access to the cvs repository. However, I
> > made some changes to the files. I've attached them here.
> 
> Weird, because I added you as a develeoper and the SourceForge doc says "At
> this time, all developers have write access to the CVS Repository and to
> your group directory (web site). There are plans to make these permissions
> optional as well. "

Operator error. I've got it worked out now. 

> 

...

> 

> That solution is fine with me but I have two comments:
> - With the current situation, _typeOfRequests is set to ('web','xmlrpc') by
> default. This means that even if the app doesn't use XML-RPC at all (which
> is probably 99% of the CherryPy apps at the moment), we'll try to parse all
> requests as XML-RPC request. For this reason, I think we should set
> _typeOfRequests to just ('web') by default, so non-xml-rpc apps won't be
> penalized.

Done. Default is just 'web'

> - When trying to parse the request body, we should probably make a special
> case when there is no body (content-length==0) because, again, this case
> will probably happend quite often.

I'm not sure I get this. I see where content-length gets evaluated in
_parsePostData, but I'm not sure what an appropriate response should be
if it's ==0.

Speaking of special cases...back to the problem of telling xmlrpc
requests from web requests:

The code I sent you last round works pretty well if the client reqeusts
something that's there, but I'm having a lot of trouble trapping
problems when the client requests, via xmlrpc, something that either
isn't there or that isn't tagged xmlrpc. 

I know the goal is to keep things simple. Because xmlrpc requests get
treated as POST requests, the need to distinguish between the two only
happens in the _parsePostData code. Would it be too simple to make the
test content-type==text/xml? 

The assumption would be that xml-rpc request would always be text/xml
and HTML POST requests would never be text/xml. If we can make that
assumption, I can move the test higher up in the xmlrpc processing and
we can go back to having both 'xmlRpc' and 'web' as our default
typeOfReqeusts. More importantly, I can code something that traps
errors.

What do you think?

Re: [Cherrypy-devel] RE: new files attached

[Steven N. <ste...@th...>]

On Wed, 2003-03-12 at 01:14, Remi Delon wrote:
> > It turns out I don't have write access to the cvs repository. However, I
> > made some changes to the files. I've attached them here.
> 
> Weird, because I added you as a develeoper and the SourceForge doc says "At
> this time, all developers have write access to the CVS Repository and to
> your group directory (web site). There are plans to make these permissions
> optional as well. "

Yes, weird. This is what I get (and yes, I am logged in!):
cvs [server aborted]: "commit" requires write access to the repository

I'll email sourceforge and ask about it.
> 
> > 1. In parseConfigFile.py, _xmlRpc has gone away and has been replaced
> > with _typeOfRequests. _typeOfRequests is a tuple that defaults to
> > ('xmlRpc','web').
> >
> > 2. In cherrypy.py, I added xmlrpcMaskAndViewMap. It shows up just about
> > everywhere hiddenMaskAndViewMap does (that's what I modelled it after).
> > However, where you remove masks and views from maskAndViewMap that occur
> > in hiddenMaskAndViewMap, I don't bother removing the masks and views
> > that are in xmlrpcMaskAndViewMap from maskAndViewMap. It seemed like
> > unnecessary  processing for a small memory savings.
> >
> > 3. I also added these lines for xmlrpcMaskAndViewMap corresponding to
> > similar lines for maskAndViewMap.
> > if _debug: f.write('global xmlrpcMaskAndViewMap\n')
> > f.write("xmlrpcMaskAndViewMap=%s\n"%`parsedModule.xmlrpcMaskAndViewMap`)
> >
> > 4. In httpTools.py, I modified the beginning of _parsePostData() and a
> > little bit of _handleRequest(). Probably a diff is the best explanation.
> >
> > 5. Of note was the creation of a new request attribute, rpcMethod, in
> > httpTools._parsePostData(). This holds the original method called, which
> > gets lost otherwise in the path/class/method processing. It's perhaps a
> > little gratuitous to hang on to it, but it happens to be something I
> > need for what I'm doing. Maybe you'll want to call it request.rawMethod
> > or something.
> >
> > 6. There were five or six lines in httpServer.py that started with
> > spaces instead of tabs. I replaced the spaces with tabs (4 spaces == 1
> > tab). I had to do this to get files compiled with '-W 2' to run.
> >
> >
> > I haven't done much testing yet, but so far this seems to meet our
> > established requirements. I know one thing I'm not properly handling is
> > sending an error to an xmlrpc client when it makes an invalid request. I
> > think I can take care of that by moving around the order of things at
> > the top of httpTools._parsePostData().
> >
> > Anyway, I thought I'd get your blessing of this before I go much
> > further.
> 
> I think it's very good so far. I have a few comments though:
> 
> - I'd like to keep a consistent style for indentation in the source files. I
> noticed that you used 2 spaces in httpTools.py to indent a block. I like to
> use one tab to indent a block. Could you use the same ? (you can set the
> tabspace to 2 spaces in your editor :)

Of course, sorry about that. 

> 
> - I saw that the solution you've chosen to solve the problem I described in
> my previous e-mail is:
> 	* try to parse the body of the request as an XML-RPC request in all cases
> 	* if the parsing fails, it means it's not an XMl-RPC request, so it must be
> a regular web request.

Yes, I'm doing a check against xmlrpcMaskAndViewMap to determine whether
the request is for XML-RPC or not, but in order to do that check, I wind
up having to do most of the XML-RPC preprocessing. As inefficient as
that is, I couldn't think of a more efficient way to go about it.

> That solution is fine with me but I have two comments:
> - With the current situation, _typeOfRequests is set to ('web','xmlrpc') by
> default. This means that even if the app doesn't use XML-RPC at all (which
> is probably 99% of the CherryPy apps at the moment), we'll try to parse all
> requests as XML-RPC request. For this reason, I think we should set
> _typeOfRequests to just ('web') by default, so non-xml-rpc apps won't be
> penalized.

That sounds like a good plan.

> - When trying to parse the request body, we should probably make a special
> case when there is no body (content-length==0) because, again, this case
> will probably happend quite often.

I'll take a look at that.

> 
> - Also, I didn't understand your comment in the code: "# @SN - Note: nested
> these because test is not valid for xmlRpc". What was that referring to ?

Well, that's not very clear is it? That's what I get for coding after
midnight. What I meant to say is that we're already checking
xmlrpcMaskAndViewMap somewhere else so we don't have to check
maskAndViewMap. I added the if: statement making the tests against
maskAndViewMap and hiddenMaskAndViewMap conditional. I did this when I
was having trouble getting the request.path properly set for XML-RPC
requests and it may not be necessary any longer. I'll do some tests and
see if I can eliminate the if: statement.
> 
> Remi.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Cherrypy-devel mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/cherrypy-devel
> 

[Cherrypy-devel] RE: new files attached

[Remi D. <re...@ch...>]

> It turns out I don't have write access to the cvs repository. However, I
> made some changes to the files. I've attached them here.

Weird, because I added you as a develeoper and the SourceForge doc says "At
this time, all developers have write access to the CVS Repository and to
your group directory (web site). There are plans to make these permissions
optional as well. "

> 1. In parseConfigFile.py, _xmlRpc has gone away and has been replaced
> with _typeOfRequests. _typeOfRequests is a tuple that defaults to
> ('xmlRpc','web').
>
> 2. In cherrypy.py, I added xmlrpcMaskAndViewMap. It shows up just about
> everywhere hiddenMaskAndViewMap does (that's what I modelled it after).
> However, where you remove masks and views from maskAndViewMap that occur
> in hiddenMaskAndViewMap, I don't bother removing the masks and views
> that are in xmlrpcMaskAndViewMap from maskAndViewMap. It seemed like
> unnecessary  processing for a small memory savings.
>
> 3. I also added these lines for xmlrpcMaskAndViewMap corresponding to
> similar lines for maskAndViewMap.
> if _debug: f.write('global xmlrpcMaskAndViewMap\n')
> f.write("xmlrpcMaskAndViewMap=%s\n"%`parsedModule.xmlrpcMaskAndViewMap`)
>
> 4. In httpTools.py, I modified the beginning of _parsePostData() and a
> little bit of _handleRequest(). Probably a diff is the best explanation.
>
> 5. Of note was the creation of a new request attribute, rpcMethod, in
> httpTools._parsePostData(). This holds the original method called, which
> gets lost otherwise in the path/class/method processing. It's perhaps a
> little gratuitous to hang on to it, but it happens to be something I
> need for what I'm doing. Maybe you'll want to call it request.rawMethod
> or something.
>
> 6. There were five or six lines in httpServer.py that started with
> spaces instead of tabs. I replaced the spaces with tabs (4 spaces == 1
> tab). I had to do this to get files compiled with '-W 2' to run.
>
>
> I haven't done much testing yet, but so far this seems to meet our
> established requirements. I know one thing I'm not properly handling is
> sending an error to an xmlrpc client when it makes an invalid request. I
> think I can take care of that by moving around the order of things at
> the top of httpTools._parsePostData().
>
> Anyway, I thought I'd get your blessing of this before I go much
> further.

I think it's very good so far. I have a few comments though:

- I'd like to keep a consistent style for indentation in the source files. I
noticed that you used 2 spaces in httpTools.py to indent a block. I like to
use one tab to indent a block. Could you use the same ? (you can set the
tabspace to 2 spaces in your editor :)

- I saw that the solution you've chosen to solve the problem I described in
my previous e-mail is:
	* try to parse the body of the request as an XML-RPC request in all cases
	* if the parsing fails, it means it's not an XMl-RPC request, so it must be
a regular web request.
That solution is fine with me but I have two comments:
- With the current situation, _typeOfRequests is set to ('web','xmlrpc') by
default. This means that even if the app doesn't use XML-RPC at all (which
is probably 99% of the CherryPy apps at the moment), we'll try to parse all
requests as XML-RPC request. For this reason, I think we should set
_typeOfRequests to just ('web') by default, so non-xml-rpc apps won't be
penalized.
- When trying to parse the request body, we should probably make a special
case when there is no body (content-length==0) because, again, this case
will probably happend quite often.

- Also, I didn't understand your comment in the code: "# @SN - Note: nested
these because test is not valid for xmlRpc". What was that referring to ?

Remi.

RE: [Cherrypy-devel] xmlrpc modifications

[Steven N. <ste...@th...>]

On Mon, 2003-03-10 at 13:51, Remi Delon wrote:
> > Good point. What about _xmlRpc and _html? _web seems more about the
> > network than the traffic.
> 
> Well, "non xmlrpc" views and masks can return anything, not just HTML ... In
> this case, I propose "_browser" because that's where the request originated
> from ...
> 

I may need another pot of tea. I'll go back to _web.

> > I haven't had a chance to look at this yet in the source...what do
> > entries in the maskAndView look like: class.method(), request.path?
> 
> Consider this:
> 
> CherryClass Root:
> mask:
>     def index(self):
>         ...
>     def home(self):
>         ...
> 
> The map (or dictionary if you prefer :-) will look like this:
> {"Root": {"index":1, "home":1}}
> 
> > > Also, we said we'd use a concatenation of request.path and the
> > methodName
> > > contained in the request body to find out the corresponding
> > > CherryClass.method (not just request.path)
> >
> > I think the part I'm missing (again, I haven't had a chance to look yet)
> > is getting a handle on which method I'm "in" to compare to the map in my
> > if statement. Will that be obvious once I get in there?
> 
> Oh no ! I just realized that it can't work the way we thought :-(
> Because in the event of an xmlRpc call, we have to parse the request body to
> get the methodName. And this methodName (along with the request.path) will
> tell us which CherryClass.method to call. And only when we know the
> CherryClass.method can we determine if it's an xmlRpc call or not !
> Do you see the problem ?
> 
I do. That's the part I couldn't figure out. I'll dive into the code a
little and see what options I can think of.

> Argh !
> 
> Anyway, I'm too tired to think about this any longer. I'm going to bed !
>

Good night. :)
 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cherrypy-devel mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/cherrypy-devel
> 

RE: [Cherrypy-devel] xmlrpc modifications

[Remi D. <re...@ch...>]

> Good point. What about _xmlRpc and _html? _web seems more about the
> network than the traffic.

Well, "non xmlrpc" views and masks can return anything, not just HTML ... In
this case, I propose "_browser" because that's where the request originated
from ...

> I haven't had a chance to look at this yet in the source...what do
> entries in the maskAndView look like: class.method(), request.path?

Consider this:

CherryClass Root:
mask:
    def index(self):
        ...
    def home(self):
        ...

The map (or dictionary if you prefer :-) will look like this:
{"Root": {"index":1, "home":1}}

> > Also, we said we'd use a concatenation of request.path and the
> methodName
> > contained in the request body to find out the corresponding
> > CherryClass.method (not just request.path)
>
> I think the part I'm missing (again, I haven't had a chance to look yet)
> is getting a handle on which method I'm "in" to compare to the map in my
> if statement. Will that be obvious once I get in there?

Oh no ! I just realized that it can't work the way we thought :-(
Because in the event of an xmlRpc call, we have to parse the request body to
get the methodName. And this methodName (along with the request.path) will
tell us which CherryClass.method to call. And only when we know the
CherryClass.method can we determine if it's an xmlRpc call or not !
Do you see the problem ?

Argh !

Anyway, I'm too tired to think about this any longer. I'm going to bed !

RE: [Cherrypy-devel] xmlrpc modifications

[Steven N. <ste...@th...>]

I think I'm mostly on track. A couple of comments/questions below.

On Mon, 2003-03-10 at 12:54, Remi Delon wrote:
> > I think 10 days may be too far out for me. I'm willing to take this on,
> > if you'll continue to answer questions. In my head, it's just a few
> > hours worth of work--I hope I'm not fooling myself.
> >
> > I just registered on sourceforge. Username: steveatwaypath.
> 
> OK, I've added you to the project as a developer. You should be able to run
> "cvs commit". If not, let me know.
> 
> 
> > A. The config file parsing is pretty straightforward. Here's what I make
> > of it.
> >
> > 1. Set default for _xmlRpc to 1
> > 2. Create a _http variable and set its default to 1
> > 3. Add parsing of typeOfRequests in the [server] block to modify these
> > values.
> 
> Sounds good. Or else you can get rid of the _xmlRpc and _http variables and
> keep the _typeOfRequests one.
> By the way, is seems more logical to oppose "_xmlRpc" to "_web" rather than
> "_http" because technically, both use the HTTP protocol ...

Good point. What about _xmlRpc and _html? _web seems more about the
network than the traffic.

> 
> > B. Next, comes parsing the type argument. I found this line in
> > cherrypy.py:
> >  if functionDef.rstrip()[-7:]=="hidden:":
> >
> > So, this looks like a good place to check for the type.
> 
> Yeah, copying what's done for "hidden" methods or classes is a good idea ...
> The code builds a map containing the CherryClasses names and methods that
> are hidden. You need to do the same for xmlRpc.
> 
> > 1. Can we say that 'hidden' and 'xmlrpc' never occur together? It makes
> > sense to me that something can't be both.
> 
> Yeah, that makes sense. If something is hidden, this means it cannot be
> accessed from the outside world, so "web" or "xmlRpc" doesn't apply ...
> 
> > C. If I follow the way you like to do things...does this make sense?
> >
> > For each supported typeOfRequest, we assign a list of methods, so we
> > wind up with:
> >  {'xmlRpc':['methodA','methodB'], 'http':['methodC', 'methodD']}
> 
> Yeah. 'http' already exists. It's called "maskAndViewMap", but you can
> rename it. Here again, I'd prefer the name "web" rather than "http".
> There is a catch when a class inherit from another one ... you have to
> inherit the methods in the map.

I haven't had a chance to look at this yet in the source...what do
entries in the maskAndView look like: class.method(), request.path?


> 
> > Then, in httpTools._parsePostData(), where you currently have:
> >
> >   if _xmlRpc and request.path=="RPC2":
> >     ...
> >   else:
> >     ...
> >
> > we put
> >
> >   if _xmlRpc and [this method is in the list above keyed on xmlRPC]:
> >     ...
> >   elif _http and [this method is in the list above keyed on http]:
> >     ...
> >   else:
> >     [error]
> >
> > Make sense so far?
> 
> Yes, very much ...
> 
> > D. If we've gotten through so far, then we're down to this:
> >
> > 1. What's the approved method for transporting the dictionary around?
> 
> Just use a global variable. The convention I tried to use so far is that if
> the user shouldn't use this variable, it starts with and underscore (ex:
> _xmlRpc). If the user can use this variable, it doesn't start with an
> underscore 'ex: request and response)
> 
> > 2. For populating the ['methodA', 'methodB'] lists and doing our
> > conditional tests, I'm thinking we just use request.path values. Does
> > that sound reasonable?
> 
> Hmm ... I'm not following... The list is populated at compile time,
> depending on the source file ! I'd actually prefer a map for that because
> the lookup is faster (check what's already done for "maskAndViewMap" and
> "hiddenMaskAndViewMap").

By map, you  

> Also, we said we'd user a concatenation of request.path and the methodName
> contained in the request body to find out the corresponding
> CherryClass.method (not just request.path)

I think the part I'm missing (again, I haven't had a chance to look yet)
is getting a handle on which method I'm "in" to compare to the map in my
if statement. Will that be obvious once I get in there?
> 
> > 3. What would you like to happen in the [error] case? I think there's a
> > "no method for this path" type error already. Any tips on how to point
> > to that?
> 
> Just leave the test where it is, and then you should never get to your final
> "else" statement.
> 
> Good luck :-)

Thanks! And thanks for letting me play.

> 
> Remi.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cherrypy-devel mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/cherrypy-devel
> 

RE: [Cherrypy-devel] xmlrpc modifications

[Remi D. <re...@ch...>]

> I think 10 days may be too far out for me. I'm willing to take this on,
> if you'll continue to answer questions. In my head, it's just a few
> hours worth of work--I hope I'm not fooling myself.
>
> I just registered on sourceforge. Username: steveatwaypath.

OK, I've added you to the project as a developer. You should be able to run
"cvs commit". If not, let me know.


> A. The config file parsing is pretty straightforward. Here's what I make
> of it.
>
> 1. Set default for _xmlRpc to 1
> 2. Create a _http variable and set its default to 1
> 3. Add parsing of typeOfRequests in the [server] block to modify these
> values.

Sounds good. Or else you can get rid of the _xmlRpc and _http variables and
keep the _typeOfRequests one.
By the way, is seems more logical to oppose "_xmlRpc" to "_web" rather than
"_http" because technically, both use the HTTP protocol ...

> B. Next, comes parsing the type argument. I found this line in
> cherrypy.py:
>  if functionDef.rstrip()[-7:]=="hidden:":
>
> So, this looks like a good place to check for the type.

Yeah, copying what's done for "hidden" methods or classes is a good idea ...
The code builds a map containing the CherryClasses names and methods that
are hidden. You need to do the same for xmlRpc.

> 1. Can we say that 'hidden' and 'xmlrpc' never occur together? It makes
> sense to me that something can't be both.

Yeah, that makes sense. If something is hidden, this means it cannot be
accessed from the outside world, so "web" or "xmlRpc" doesn't apply ...

> C. If I follow the way you like to do things...does this make sense?
>
> For each supported typeOfRequest, we assign a list of methods, so we
> wind up with:
>  {'xmlRpc':['methodA','methodB'], 'http':['methodC', 'methodD']}

Yeah. 'http' already exists. It's called "maskAndViewMap", but you can
rename it. Here again, I'd prefer the name "web" rather than "http".
There is a catch when a class inherit from another one ... you have to
inherit the methods in the map.

> Then, in httpTools._parsePostData(), where you currently have:
>
>   if _xmlRpc and request.path=="RPC2":
>     ...
>   else:
>     ...
>
> we put
>
>   if _xmlRpc and [this method is in the list above keyed on xmlRPC]:
>     ...
>   elif _http and [this method is in the list above keyed on http]:
>     ...
>   else:
>     [error]
>
> Make sense so far?

Yes, very much ...

> D. If we've gotten through so far, then we're down to this:
>
> 1. What's the approved method for transporting the dictionary around?

Just use a global variable. The convention I tried to use so far is that if
the user shouldn't use this variable, it starts with and underscore (ex:
_xmlRpc). If the user can use this variable, it doesn't start with an
underscore 'ex: request and response)

> 2. For populating the ['methodA', 'methodB'] lists and doing our
> conditional tests, I'm thinking we just use request.path values. Does
> that sound reasonable?

Hmm ... I'm not following... The list is populated at compile time,
depending on the source file ! I'd actually prefer a map for that because
the lookup is faster (check what's already done for "maskAndViewMap" and
"hiddenMaskAndViewMap").

Also, we said we'd user a concatenation of request.path and the methodName
contained in the request body to find out the corresponding
CherryClass.method (not just request.path)

> 3. What would you like to happen in the [error] case? I think there's a
> "no method for this path" type error already. Any tips on how to point
> to that?

Just leave the test where it is, and then you should never get to your final
"else" statement.

Good luck :-)

Remi.