Re: CherryPy WSGI server and wsgi.input.read() with no argument.

On 30/03/07, James Y Knight <foomfuhm.net> wrote:
>
> On Mar 29, 2007, at 6:09 PM, Graham Dumpleton wrote:
> > On 30/03/07, Robert Brewer <fumanchuamor.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
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com