[Web-SIG] Other kinds of environment variables

[Phillip J. Eby]

At 08:44 PM 8/26/04 -0700, Mark Nottingham wrote:

>On Aug 26, 2004, at 5:03 PM, Ian Bicking wrote:
>
>>>* cache validation - does the server handle If-Modified-Since and 
>>>If-None-Match requests appropriately (e.g., with a 304)?
>>
>>I would almost certainly expect this to be false.  There may be some WSGI 
>>servers that have an extended notion of the application, so they can look 
>>at things like the modification date.  But those are likely to be 
>>uncommon -- more likely only applications will know the necessary information.
>
>Apache CGI does it; i.e., if you set a Last-Modified header, it'll 
>automagically handle validation for you.

I guess the relevance of this depends on whether bandwidth or CPU is the 
scarcer resource.  If you want to save CPU, the application should do this, 
so it doesn't have to produce a response body it doesn't need.  If all you 
care about is bandwidth, then certainly the server can truncate the body.

I'm inclined to make this guideline permissive: a server *may* treat 
write() as a no-op and change the status if it can do so safely.  But I 
don't think servers should be required to do this.


[Ian:]
>>When I think of middleware, I can think of many things like this.  In 
>>most cases, I'd add a key, and if the key wasn't present I'd know it was 
>>false.  But it can be odd.  Say I have a middleware that catches 
>>exceptions, because that's my one example at the moment.  If it is 
>>present, it would be nice if other applications didn't catch exceptions, 
>>and let them propagate all the way up.  So, the application looks for 
>>environ.get('ianb_middleware.exception_catcher')?  That's weird, because 
>>someone else comes along and makes their own exception catcher that works 
>>like mine; what key do they use?  It would be nice if we used the same key.

I'm somewhat negative on this concept; to me an application should be 
responsible for catching its own exceptions, or require a middleware 
wrapping for it.  The server/gateway *has* to be responsible for catching 
any otherwise uncaught exceptions.  I don't really get the concept of 
wanting to *not* catch exceptions.  If you have a two-layer model 
(app+exception catcher), just put the handler you want to use in place as 
middleware.  If the app has its own exception handling, surely it knows 
better how to handle the exception than anything else, so why change?


[Mark:]
>I can totally see this stuff happening on a more ad hoc basis. We did 
>similar things at Akamai; i.e., putting together a dynamically-configured 
>pipeline of handlers to implement HTTP functionality, as well as content 
>transforms. Very useful and very cool.

Ah, now I see why you know so much about HTTP/1.1 issues "in the field".  :)