[Web-SIG] Other kinds of environment variables
jim-web-sig at jimdabell.com
Fri Aug 27 04:17:02 CEST 2004
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
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
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.
More information about the Web-SIG