[Web-SIG] Other kinds of environment variables

[Mark Nottingham]

One thing that seems to be missing in WSGI to me is the communication 
of the delineation between what the server does and what the 
application does.

The latest drafts says;

[[[
In general, the server or gateway is responsible for ensuring that 
correct headers are sent to the client: if an application omits a 
needed header, the server or gateway *shoud* add it. [...] If the 
application supplies a header that the server would ordinarily supply, 
or that contradicts the server's intended behaviour [...] the server or 
gateway *may* discard the conflicting header, provided that its action 
is recorded for the benefit of the application author.
]]]

I'm a bit uncomfortable with this, because there's no standard way for 
the action to be "recorded for the benefit of the application author." 
IMO this is one of the major problems with CGI.

In other words, there's a laundry list of HTTP features that may or may 
not be handled by the server on behalf of the application, depending on 
how it's written and configured. Giving the application some idea of 
what it can expect the server to do, and how it will do it, would help 
application frameworks decide what tasks it needs to take on itself.

For example;

* HTTP auth - does the server make the Authentication header available? 
Automatically generate 401s when configured to require auth? If the 
application framework wishes to perform auth on its own, will it have 
the appropriate information available?
* chunked encoding - does the server chunk the body when appropriate?
* content-length - does the server automatically calculate it?
* cache validation - does the server handle If-Modified-Since and 
If-None-Match requests appropriately (e.g., with a 304)?
* content-encoding - does the server apply content-encoding in requests 
and/or responses as appropriate, and what schemes does it support?
* transfer-encoding - same as content-encoding

Some servers (e.g., CGI) may not be able to supply all of this 
information reliably, but others will, and it would be quite useful to 
frameworks to know the capabilities of the server in a generic fashion.

I know that this can be addressed by server-specific environment now, 
but I think there might be some low-hanging fruit for common functions 
like the ones above. It might be that they'd be better in a separate 
document, so they're not part of the 'core' WSGI, but I think there's 
real value in having some common ones.

Thoughts? If there's interest, I'll make a proposal.


--
Mark Nottingham     http://www.mnot.net/