2008/12/31 Graham Dumpleton <[email protected]>: > BTW, an important distinction is that Opera is expecting a > 100-continue response before sending actual data. Apache stuffs up > 100-continue processing and mod_wsgi tries to workaround its mistake. > > What version of Apache are you using, and does the same code work when > run in embedded mode of mod_wsgi?
The issue here is definitely with the 100-continue feature. Opera is the only browser I know of which tries to use this feature, but it only does so when post data is greater than 10KB in size. For reasons I don't understand yet, Apache is returning an end of stream marker on first read of bucket chain when trying to read input when proxying it across to daemon process. I saw this previously with 'curl' and although tried to work it out a couple of times, hadn't as yet. What I didn't understand was that if I did a much simpler test of 100-continue support using telnet against http port, it worked fine. Since Opera seems also to trigger issue, it must be something to do with all the extra headers that curl and Opera pass in the request. Something in there is causing Apache to do the wrong thing. What I also don't understand is that the code used to read the bucket chain for input when proxying is basically the same as is used in mod_cgi and mod_cgid . Thus any issue in Apache itself if it exists would have to affect CGI scripts as well. I will go back and do some more digging now that know it isn't just an issue with curl. Graham > 2008/12/31 Graham Dumpleton <[email protected]>: >> Difference in posted content length will be due to different >> separation boundary in multipart post. The question is with that >> logging code from debugging page in wiki, what is the actual amount of >> post content that was delivered by each client and did it match the >> content length in request header. >> >> Graham >> >> 2008/12/31 whuuu <[email protected]>: >>> >>> FF: >>> >>> User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.9.0.3) Gecko/ >>> 2008092623 Firefox/3.0.3 >>> >>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/ >>> *;q=0.8 >>> >>> Accept-Language: en-us,en;q=0.5 >>> >>> Accept-Encoding: gzip,deflate >>> >>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 >>> >>> Keep-Alive: 300 >>> >>> Connection: keep-alive >>> >>> Content-Type: multipart/form-data; >>> boundary=---------------------------523970165160586190745423760 >>> >>> Content-Length: 2693550 >>> >>> >>> Opera: >>> >>> POST /group/3/manage_grouppicture_save HTTP/1.1 >>> >>> User-Agent: Opera/9.62 (X11; Linux i686; U; de) Presto/2.1.1 >>> >>> Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/ >>> png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 >>> >>> Accept-Language: de-DE,de;q=0.9,en;q=0.8 >>> >>> Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 >>> >>> Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 >>> >>> Expect: 100-continue >>> >>> Connection: Keep-Alive >>> >>> Content-Length: 2693506 >>> >>> Content-Type: multipart/form-data; boundary=---------- >>> raXwlYmtJiMEEDq2SIyPMz >>> >>> On Dec 31, 1:28 am, "Graham Dumpleton" <[email protected]> >>> wrote: >>>> 2008/12/31 Graham Dumpleton <[email protected]>: >>>> >>>> >>>> >>>> > 2008/12/31 whuuu <[email protected]>: >>>> >>>> >> hey guys, >>>> >>>> >> i got a really strange problem: >>>> >>>> >> Do you have any idea what could cause 'Request body truncated' when >>>> >> uploading files using mod_wsgi? >>>> >> The error just appears when using Opera as browser and mod_wsgi. >>>> >> Upload files using Firefox works (even with mod_wsgi) and uploading >>>> >> files using Opera with pylons' development server works, as well. >>>> >>>> >> mod_wsgi (pid=12318): Exception occurred processing WSGI script '/home/ >>>> >> test/env/projects/portal_en.wsgi'. >>>> >> Traceback (most recent call last): >>>> >> File "/home/test/env/lib/python2.5/site-packages/Paste-1.7.2-py2.5.egg/ >>>> >> paste/cascade.py", line 102, in __call__ >>>> >> raise IOError("Request body truncated") >>>> >> IOError: Request body truncate >>>> >>>> >> I'm using mod_wsgi 2.3 (lenny) and running my app in daemon mode. >>>> >>>> > Do you have Apache setup to allow compressed request content. >>>> >>>> > Ie., Apache has: >>>> >>>> > SetInputFilter DEFLATE >>>> >>>> > and HTTP request is setting: >>>> >>>> > Content-Encoding: gzip >>>> >>>> > WSGI doesn't really support mutating input filters and the checks that >>>> > Paste cascade is doing would bork if such a thing it present. >>>> >>>> > Otherwise, I need to look more closely at what Paste cascade is doing >>>> > any whether it guarantees that all applications in cascade will see >>>> > full input, or if earlier one consuming any input will mean latter >>>> > will not see it all. >>>> >>>> Actually, compressed input would actually work the opposite way and >>>> generally mean there would be more input available than original >>>> content length. >>>> >>>> Either way, suggest applying second recipe in: >>>> >>>> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Re... >>>> >>>> to record all request content and headers. Can then look at whether >>>> such headers are set or not, or whether Content-Length even matches >>>> posted content by looking at how much stored in input file for the >>>> request. >>>> >>>> Graham >>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
