|
Graham Dumpleton
grahamd at dscpl.com.au
Fri Jan 12 17:28:08 EST 2007
If you are using mod_python 3.2.10 or earlier, try 3.3.0b as it has some fixes to FieldStorage class. Can be downloaded from: http://httpd.apache.org/modules/python-download.cgi I suspect though that it still will not work though, as code is: # figure out boundary try: i = ctype.lower().rindex("boundary=") boundary = ctype[i+9:] if len(boundary) >= 2 and boundary[0] == boundary[-1] == '"': boundary = boundary[1:-1] boundary = re.compile("--" + re.escape(boundary) + "(--)? \r?\n") Ie., it assumes that boundary is last field on content type line which is a bad assumption. Graham On 13/01/2007, at 8:41 AM, Emiliano Moscato wrote: > Hi all! > > Thanks for your answers. > I've been looking the code of FieldStorage and publisher. I think > it is not soo dificult to patch FieldStorage, but: Is anybody else > interested in patch FieldStorage? If so I'll try it on monday. > > On the other hand, I've trying to use another method to send my > xforms which uses "multipart/related" as Content-type and I > realized that mozilla xforms plugin sends a boundary that is bad > handled by publisher-FieldStorage. This is what browser sends: > > [...] > Content-Length: 522 > Content-Type: multipart/related; > boundary=---------------------------13592280651221337293469391600; > type="application/xml"; start="<4c599da9.58c746e8 at mozilla.org >" > Cookie: lang=1 > > -----------------------------13592280651221337293469391600 > Content-Type: application/xml > Content-ID: <4c599da9.58c746e8 at mozilla.org> > > <?xml version="1.0" encoding="UTF-8"?> > <idioma xmlns:xf="http://www.w3.org/2002/xforms" xmlns:ev=" http:// > www.w3.org/2001/xml-events" xmlns:xsi="http://www.w3.org/2001/ > XMLSchema-instance" xmlns:xsd=" http://www.w3.org/2001/XMLSchema"> > > <H__interface>main</H__interface> > <idioma>adadsfasd</idioma> > </idioma> > -----------------------------13592280651221337293469391600-- > > > But FieldStorage parse the content-type line up to the end trying > to get boundary, getting this as boundary: > -----------------------------7393760691212604279930853199; > type="application/xml"; start="< b8f2849.19571884 at mozilla.org> > > Is this a firefox problem or a FieldStorage problem? > Regards, enjoy the weekend :) > > Emiliano > > > 2007/1/12, Jim Gallacher <jpg at jgassociates.ca>: > Graham Dumpleton wrote: > > Jim Gallacher wrote .. > >> Emiliano Moscato wrote: > >>> Hi all! > >>> > >>> I'm getting crazy trying to receive xforms xml data with > mod_python + > >>> publisher handler. > > > > In what way are you using mod_python.publisher? Depending to what > > degree you are using it, mod_python 3.3 offers some alternate > mechanisms > > for doing basic dispatch against different resources which might > be more > > useful and allow you to still access content of response to > decode it. > > > >>> In a normal HTML form, the data would be sent as > >>> application/x-www-form-urlencoded, in the XForms world however, > this > >>> information is sent as XML formatted data (application/xml). > >>> Up to now I've used cherryPy as web server and I've got my xml > data with > >>> cherrypy.threadData.xform. > >>> I've read that PHP receive this in $HTTP_RAW_POST_DATA > variable. If I > >> send > >>> the form to a php script all work fine. > >>> But when I try to submit a xforms with method POST to a script > managed > >> by > >>> publisher handler I get an error with no log in my apache > server error > >> log. > >>> Any help? > >> You'll need to elaborate on the error you are getting, but I > think part > >> of the problem is that you are bumping up against part of the > internal > >> "magic" of publisher. > >> > >> Publisher automatically creates a FieldStorage instance. > Unfortunately > >> FieldStorage assumes that the content-type starts with either > >> "application/x-www-form-urlencoded" or "multipart/". If I had to > guess > >> I'd say that you are getting "501 Not Implemented error" as a > result. > >> > >> Here are a couple of solutions that you might consider as a > workaround: > >> > >> 1. Hack util.FieldStorage to properly handle your content-type. > If you > >> do this feel free to submit a patch so FieldStorage can be > fixed. ;) > > > > Hmmm, xforms is quite different. > > > > http://www.w3.org/TR/xforms/ > > > > Looks like a lot of work. > > Probably. I certainly wasn't offering to do it. ;) > > >> 2. Hack publisher to skip the automatic creation of > FieldStorage. (Line > >> 424 in publisher.py for mod_python 3.3.0b). You can then use > req.read() > >> to read and process the POST'd data within your content handler. > > > > I've raised this issue before about publisher not being able to > accept other > > content types. See: > > > > http://issues.apache.org/jira/browse/MODPYTHON-29 > > > > Also, like PSP now does, publisher could be made to use > 'req.form' if it > > already existed. This would allow a stacked response handler before > > publisher to decide whether some other form content was supplied, > decode > > it and set req.form to a compatible class to FieldStorage. I > don't know that I > > have created an issue for that idea before, but have certainly > thought > > about it and perhaps mentioned it on the mailing list. > > That seems like a reasonable solution. > > >> 3. Use a PythonFixupHandler before the content handler. In the > >> fixuphandler use req.read() to grab the raw data and adjust the > >> content-type header so that FieldStorage doesn't bomb out. Note > that if > >> you want to pass xml field data as parameters to your handler > method > >> you'll need to do a bit more work. For example > >> > >> def index(foo="bar"): > >> return "whatever" > >> > >> won't get foo from your xml data. You can likely work around > this but > >> you'll need to take a look at the source for FieldStorage and > publisher > >> to work out a strategy. > > > > If you are talking about modifying the input stream, an input > filter would > > perhaps be better. Not sure that that will help since xforms is > quite > > different and isn't just a matter of changing content type. > > No, I was just thinking you could get the raw data with req.read() > (parsing the xml or whatever) and then set the content-type to > application/x-www-form-urlencoded. That way the subsequent call to > FieldStorage within publisher won't bomb out. The code would look > something like this: > > def fixuphandler(req): > if req.headers_in.has_key("content-type"): > ctype = req.headers_in["content-type"] > if ctype.startswith("application/xml"): > req.data = parse_the_xml_data_or_whatever(req.read()) > req.headers_in["content-type"] = > "application/x-www-form-urlencoded" > return apache.OK > > A little too hackish perhaps? (Assuming it would even work). > > Jim > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python > > > > -- > mOsKi > "No hay nada que uno haga mal , lo que hay es poco vino." Autor > Anonimo > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20070113/a86cb0db/attachment.html
|