[Web-SIG] WSGI tests

[Ian Bicking]

Phillip J. Eby wrote:
> At 11:47 PM 9/28/04 -0500, Ian Bicking wrote:
> 
>> Then there's the lint middleware.  This doesn't modify the request in 
>> any way (though it does wrap start_response and other objects).
> 
> 
> The wrapper is broken: 'exc_info = args[3]' should be 'exc_info = args[2]'.

Fixed.

> 
>>   It just checks various things; right now it mostly checks that 
>> required environmental variables are there and that everything is of 
>> the right type.
> 
> 
> Some of the variables you're checking for are not actually required any 
> more; see
> 
>     http://www.python.org/peps/pep-0333.html#environ-variables
> 
> for details.

The only one I was mistakenly requiring seems to be QUERY_STRING; from 
my reading, all these are required:

'REQUEST_METHOD', 'SCRIPT_NAME', 'PATH_INFO', 'SERVER_NAME', 'SERVER_PORT'

Well, maybe SCRIPT_NAME isn't required.

> Also, your header checks are requiring non-duplicated headers, but 
> duplicate header names are in fact allowed, per discussion on the list.  
> But, this isn't explicitly stated in the spec, so I should fix that.
> 
> I'm also not positive that a Content-Type header is absolutely required, 
> e.g. for redirects.  I guess I should dig up the HTTP spec on this point.

I believe it is required for any response that has a body, but it's true 
that's not all responses.  There's some 2xx responses that have no body. 
  I've taken out the requirement, but noted that it should be in there 
somewhere.  I'm okay if this embodies some requirements of HTTP 
inaddition to specifically WSGI requirements.

>>   It doesn't test any of the more subtle aspects of WSGI, or test any 
>> failure cases.
> 
> 
> Apart from the fact that it doesn't always return an iterable, the lint 
> app is WSGI compliant, but "overprotective", in that it requires things 
> not required by the spec.
> 
> Other than those nits, it's a pretty nice piece of middleware and I'll 
> probably use it to help in writing a WSGI "reference library".
> 
> 
>>   It doesn't test the exc_info stuff either; I haven't kept up, and I 
>> only partly understand the motivation there.
> 
> 
> exc_info should be a three-element tuple containing a type, an instance 
> of the type, and a traceback object.  If start_response() is called more 
> than once, it's a fatal error not to include exc_info (because the only 
> time it's valid to call start_response() a second time is if an error 
> occurred while you were writing or yielding output).  If exc_info is 
> supplied and headers have already been sent to the server, the server 
> *must* raise an error, and *should* raise the supplied exc_info 
> triplet.  So, some of these things can be tested by your 'lint' program.

I suppose I could trigger these conditions in echo, and then test that 
they are handled properly in lint.  I'll have to think about what 
exactly "properly" is first.

> See also:
> 
>     http://www.python.org/peps/pep-0333.html#the-start-response-callable
> 
> from paragraph 7 on.

I read that, and didn't feel entirely clear on the intention.  An 
example in that section would probably be helpful.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org