On Apr 16, 6:20 am, usaar33 <usaa...@gmail.com> wrote:
> Ah, I suspect the request.form code in mod_python must do doing block
> read. Either way, it worked for me.
It will work with Apache/mod_wsgi as well, but by doing so you are
breaking WSGI 1.0 standard. Use a different WSGI hosting mechanism and
it may not work though. It works in Apache/mod_wsgi as it sensibly
implements end of stream indicator by returning empty string. As I
said, that isn't a requirement of WSGI 1.0 however.
> So in conclusion, it sounds like there is either an issue with A)
> mod_deflate not modifying the header or
It can't modify the header as when streaming it will not know the new
content length until stream is uncompressed. At that point the
original headers have been long gone. For it to buffer the
uncompressed stream to calculate the new header length wouldn't be
practical as would have to save it to file as could be too big to hold
in memory.
> B) WSGI 1.0 being wrong.
WGSI 1.0 is deficient.
> 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?
If you mean remove content length in request from client, the answer
is no. This is because for normal post you are required to have it.
You can avoid it if using chunked request content, however WSGI 1.0
doesn't support chunked request content, nor does mod_python. Apache/
mod_wsgi 3.0 does allow chunked request content, but again, to make
use of it you are stepping outside of what WSGI 1.0 allows.
Graham
> On Apr 15, 3:55 am, Graham Dumpleton <graham.dumple...@gmail.com>
> 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 <graham.dumple...@gmail.com>
> > wrote:> On Apr 15, 7:44 pm, usaar33 <usaa...@gmail.com> 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 <usaa...@gmail.com> 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 django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
