Ah, I suspect the request.form code in mod_python must do doing block read. Either way, it worked for me.
So in conclusion, it sounds like there is either an issue with A) mod_deflate not modifying the header or B) WSGI 1.0 being wrong. Interestingly, there was a large debate on this 4 years ago with tomcat: https://issues.apache.org/bugzilla/show_bug.cgi?id=34526 Is the best answer for me to simply not provide content-length, which under WSGI should figure it out? On Apr 15, 3:55 am, Graham Dumpleton <[email protected]> wrote: > Oh, reading past content length also will not necessarily work in > mod_python due to bugs it has: > > http://issues.apache.org/jira/browse/MODPYTHON-212 > > If you read in blocks may be okay, but not if you try and read all > data in one go. > > Graham > > On Apr 15, 8:44 pm, Graham Dumpleton <[email protected]> > wrote:> On Apr 15, 7:44 pm, usaar33 <[email protected]> wrote: > > > > I just looked at the source code. This is a django bug. > > > Ticket filed @http://code.djangoproject.com/ticket/10819 > > > When Apache is decompressing the content you run up against a > > limitation in way mutating input filters are dealt with. > > > Namely, when request content is decompressed, the content length in > > the headers isn't updated to the actual final length of data. Thus, if > > an application only reads up to content length, rather than all > > available input, then it will truncate the data. > > > The only problem is that WSGI specification, which I know you aren't > > using here, forbids you reading more than content length. Thus Django > > cannot be changed in the way that ticket suggests as by ignoring > > content length it would be in violation of WSGI specification and may > > not work on all WSGI hosting mechanisms. > > > This is an issue which will hopefully be dealt with in WSGI 2.0 > > specification. > > > Graham > > > > On Apr 15, 1:41 am, usaar33 <[email protected]> wrote: > > > > > Hello, > > > > For my application, I am using using gzip content-encoding to > > > > compress POSTDATA that the client is giving to django. The actual > > > > content-type is multipart/form-data (although django is screwing up on > > > > any content-type). mod_deflate is used to decompress data coming in > > > > from the client. > > > > I have verified that with mod_python that all postdata is there (it > > > > is even split correctly into req.form correctly). > > > > > Unfortunately, django appears to be truncating the data in its > > > > parsing. Only a fixed amount (perhaps 200ish bytes?) are being placed > > > > into request.POST; some fields are missing and the last field in the > > > > dictionary is being truncated. > > > > > Without ciient-side compression this does not occur. > > > > > Has anyone seen this behavior? Does anyone know how to fix it? > > > > > Best, > > > > Aaron Staley --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
