[Web-SIG] CherryPy WSGI server and wsgi.input.read() with no argument.

[Graham Dumpleton]

On 30/03/07, James Y Knight <foom at fuhm.net> wrote:
>
> On Mar 29, 2007, at 6:09 PM, Graham Dumpleton wrote:
> > On 30/03/07, Robert Brewer <fumanchu at amor.org> wrote:
> >
> >> We chose to not simulate the EOF, requiring app authors do that for
> >> themselves
>
> CherryPy's deveopers are correct: they are following the WSGI spec.
> It is your app that is broken.

Since my app is a ten line test program just to test what the CherryPy
WSGI server does, I am not too concerned. :-)

> This requirement comes from CGI. CGI scripts cannot support unknown
> data lengths (yes, this means no chunked transfer). CONTENT_LENGTH is
> required to be provided if there is data, and the server is not
> required to provide an EOF after reading CONTENT_LENGTH bytes. WSGI
> inherits the same restrictions.
>
> I do agree with you that this was a mistake. WSGI should require WSGI
> servers/gateway to provide an EOF for read(), always, and should make
> a break from CGI and declare that CONTENT_LENGTH=0 means no data and
> CONTENT_LENGTH empty/missing means undefined length. This is
> something which ought to be fixed for the next revision of WSGI. This
> makes it a tiny bit harder to write a CGI gateway, of course, but
> it's worth it in my opinion, for the reasons you describe.
>
> HOWEVER, given that the current WSGI spec does not specify that, apps
> *cannot* depend upon that behavior. If your app does an unbounded read
> (), it's wrong. And, by reference to the CGI spec, if a server omits
> CONTENT_LENGTH, and there is data, it is wrong. The server ought to
> return a 411 Length Required if you attempt to access a WSGI app and
> provide chunked data.
>
> And, indeed, server code I wrote is wrong in just this way: it can
> omit CONTENT_LENGTH when given chunked data on input. Spec-compliant
> WSGI apps would then assume there's no input data which will then
> cause data loss. Luckily nobody ever passes chunked data on input. :)
>
> James
>
> PS: what about the readline(size) problem? Are we just going to
> continue indefinitely pretending that it's okay that the spec forbids
> using readline(size) and that cgi.FieldStorage calls it? Perhaps a
> WSGI 1.1 fixing these issues would be a good idea?

At least we agree on the problems with the WSGI specification.

My problem now is that in mod_wsgi do I implement it exactly as per
the WSGI 1.0 specification and thus propagate these problems and
limitations (and thereby block use of cgi.FieldStorage), or if we can
get some forward looking consensus on what WGSI 1.1 should do,
implement to that instead.

I would rather address the problems now as in the Apache world, once
an Apache module gets installed, especially by a web hosting provider,
it stays at that version for ages. On the mod_python list we still
have to deal with people using older versions of mod_python
2.7/3.0/3.1 which are many years old even though we are up to
mod_python 3.3 now.

I could also just implement what makes the most sense even if people
don't want to agree on a general consensus that that is what WSGI 1.1
should do. As far as I can see so far, this would still be WSGI 1.0
compliant, but what is the point if a WSGI 1.0 compliant application
can't make use of it and whereby WSGI 1.1 may never come out or be
different anyway.

Graham