[Web-SIG] Other kinds of environment variables

[Jim Dabell]

On Friday 27 August 2004 02:42, Phillip J. Eby wrote:
> At 03:57 PM 8/26/04 -0700, Mark Nottingham wrote:
> >* cache validation - does the server handle If-Modified-Since and
> >If-None-Match requests appropriately (e.g., with a 304)?
>
> IMO this is an application responsibility; given dynamic content, how can
> the server verify these?

In my opinion this is a middleware responsibility.  Look at the headers 
supplied by the client, put off beginning the response until all the response 
headers are retrieved from the application, and respond with a 304 where 
appropriate.

Are there any situations you can think of where an application would want to 
generate a matching Last-Modified or ETag header but not generate a 304?  If 
that happens, what stops an intermediate proxy from throwing the response 
body away and responding with a 304 itself?


> >* 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
>
> Do you have any suggestions?  My assumption is that the server should
> "first do no harm".  That is, the server shouldn't silently "value-add"
> encodings unless it's absolutely sure it's okay to do so, or a human has
> configured it to do so.

I think the constraints RFC 2616 puts on HTTP proxies should apply to 
servers/middleware because that's essentially what they are.  Basically, any 
transformation can occur as long as the server/middleware understands the 
relevant parts of the protocol, even to the point of transforming from one 
media type to another (as long as cache-control: no-transform isn't 
encountered, of course).

If a downstream proxy can make comprehensive changes to the message without 
any authorisation beyond sitting between the two parties, I think 
servers/middleware should be at least as free.


> >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.
>
> I think it certainly would be useful to have a comprehensive set of
> guidelines for how to use, provide, or apply HTTP/1.1 features in
> WSGI.

I agree that having this in a separate document is the best approach, but I 
don't think that it's something specific to WSGI.  Last time I checked, the 
Atom guys also felt the need to have a best practices document in relation to 
HTTP usage, so perhaps a collaboration is in order?  I seem to remember a 
"common pitfalls" type document from the W3C from a few years ago as well, 
but I've failed to dig anything up so far.


-- 
Jim Dabell