[Web-SIG] start_response and error checking

[Graham Dumpleton]

On 28/09/2007, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 12:54 PM 9/25/2007 +0200, Manlio Perillo wrote:
> >The WSGI spec says that start_response callable *must not* actually
> >transmit the response headers. Instead, it must store them.
> >
> >The problem is that it says nothing about errors checking.
> >As an example the Apache mod_wsgi implementation only checks that the
> >objects is a Python List Object.
> >
> >This means that I can do:
> >
> >start_response('200 OK', [1, 2, 3])
> >
> >with no exception being raised (the exception will only be raise when I
> >attempt to write some data).
> >
> >Is this the intentend behaviour?
>
> No.  start_response() *should* raise an error when given the bad
> data.  This should probably be fixed in the PEP.
>
>
> >P.S.:
> >I'm not sure, but it seems that Apache mod_wsgi allows status code with
> >more then 3 digits, without reporting an error.
> >Again, is this the intented, conforming, behaviour?
>
> No.  It should be rejected.  In general, a WSGI server *should*
> reject bad input as soon as it receives it.
>
> All that being said, these points are "shoulds" rather than
> "musts".  A good implementation should implement them.

Except that in both cases, depending on the underlying web server it
may not be reasonable, practical or efficient to do full depth data
checking on inputs at that time. In the case of Apache mod_wsgi which
is being used as an example, checks on the validity of data is done
and an error will be raised but at a later point. It is this way in
part because Apache isn't a solution whose purpose is only to support
a WSGI application and nothing else, it has to work in with other
features provided by Apache and the mechanisms which have to be used
to converse with Apache. Thus it is more appropriate, or simpler to
delay the checks, but the checks are still done.

FWIW, mod_wsgi error checking in this is actually somewhat better than
various other solutions which don't even do type checking on the
status or values in the header tuple. Ie., various implementations do
the equivalent of:

             sys.stdout.write('Status: %s\r\n' % status)
             for header in response_headers:
                 sys.stdout.write('%s: %s\r\n' % header)

This particular example code is actually taken from the WSGI
specification itself. End result is that one could supply a malformed
status line or a header tuple which consists of non string values but
they will be converted to a string without any complaint. Such things
will be flagged with mod_wsgi.

At what point any data is rejected is I don't think the real issue as
long as it is rejected. The bigger problem is with all the
implementations which allow wrongly typed or malformed values through
as that code isn't portable and isn't being flagged as non portable.
Thus when you move the code to another implementation it may break.

Graham