On Jul 8, 2:50 am, Ian Bicking <ianbick...@gmail.com> wrote:
> On Mon, Jul 6, 2009 at 8:54 PM, Chris Moyer <koper...@gmail.com> wrote:
>
> > I'm looking for chucked request content, sorry for the confusion.
>
> > I'm currently working on an implementation of a WebDav server using
> > paste and webob but I've discovered that OSX sends large files as
> > chunked transfers when using the finder. After digging around I found
> > the mention that the past server does not "yet" support this, which
> > made me assume it eventually will. The request objects as of now have
> > the ability to read in the body or provide a file-like object to read,
> > but these simply do not work for chunked encoding.
>
> > I've been trying to steer away from apache just for WSGI, but it
> > sounds like I'll have to stick with it for a while at least.
>
> There's not much active work on the Paste http server, so barring a patch
> there won't be support soon. I believe the CherryPy server does have
> support for that though (I'm assuming it just reads the request body in its
> entirety before invoking the WSGI application;
Yes, that is what CherryPy does. Not sure what measures it has to stop
really big posts given that no way to stream data to application.
> is that also what mod_wsgi does?)
No, that is not what Apache/mod_wsgi does.
In Apache/mod_wsgi it implements return of end sentinel for input
stream. Ie., provides empty string for read() when no more data. Thus,
if you want to ignore the WSGI application requirement of not reading
more than CONTENT_LENGTH, then you can just read until no more data.
I have always thought it rather stupid that WSGI application has that
requirement because it means that WSGI applications have to count the
amount of data read and ensure they do a partial read on last bit to
avoid reading more than CONTENT_LENGTH. With the end sentinel
implemented like normal file like object, you could instead just say:
s = wsgi.input.read(BLKSIZE)
while s:
... process s
s = wsgi.input.read(BLKSIZE)
The only time one would need to consult CONTENT_LENGTH is where you
want to provide a request entity too large error response. If you want
to be able to handle chunked content, currently though would also need
to look at HTTP_TRANSFER_ENCODING since WSGI doesn't have a separate
way of saying that request content length is unknown, as opposed to
zero length.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Paste Users" group.
To post to this group, send email to paste-users@???
To unsubscribe from this group, send email to paste-users+unsubscribe@???
For more options, visit this group at
http://groups.google.com/group/paste-users?hl=en
-~----------~----~----~----~------~----~------~--~---
