[Web-SIG] Other kinds of environment variables
Phillip J. Eby
pje at telecommunity.com
Fri Aug 27 03:42:22 CEST 2004
At 03:57 PM 8/26/04 -0700, Mark Nottingham wrote:
>* 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?
This is already a problem today, I'm afraid. For example, Apache 1.x
doesn't normally supply this header to CGI applications at least. (Which
is really silly, IMO, because using REMOTE_USER instead can leads to
serious security issues in shared hosting environments.)
Anyway, I think this is one that has to remain an unspecified
deployment-specific issue. No sane framework targeting multiple web
servers is going to rely solely on HTTP basic-auth if it can avoid it
anyway. Basic-auth sucks on far too many levels. I'm not saying that it
doesn't have its niche, I'm just saying that I don't think we can make any
guarantees about it in the WSGI spec without breaking something.
>* chunked encoding - does the server chunk the body when appropriate?
>* content-length - does the server automatically calculate it?
There's a section on both of these in the current draft, just not the last
one I posted. I sent a copy to peps at python.org, but haven't gotten a reply
Here's the relevant section from the latest draft:
"""Handling the ``Content-Length`` Header
If the application does not supply a ``Content-Length`` header, a
server or gateway may choose one of several approaches to handling
it. The simplest of these is to close the client connection when
the response is completed.
Under some circumstances, however, the server or gateway may be
able to either generate a ``Content-Length`` header, or at least
avoid the need to close the client connection. If the application
does *not* call the ``write()`` callable, and returns an iterable
whose ``len()`` is 1, then the server can automatically determine
``Content-Length`` by taking the length of the first string yielded
by the iterable.
And, if the server and client both support HTTP/1.1 "chunked
encoding" _, then the server *may* use chunked encoding to send
a chunk for each ``write()`` call or string yielded by the iterable,
thus generating a ``Content-Length`` header for each chunk. This
allows the server to keep the client connection alive, if it wishes
to do so. Note that the server *must* comply fully with RFC 2616 when
doing this, or else fall back to one of the other strategies for
dealing with the absence of ``Content-Length``.
>* 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?
>* 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 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. Judging from your input so far, I'd say you have a better handle on
the subject than I do, so your contribution would be very welcome. It may
indeed make sense to create a separate PEP for them, since they will mainly
be needed by server authors and by people who need to make use of some set
of HTTP/1.1 features.
Other areas that need to be addressed within HTTP/1.1 probably also
includes things like byte ranges.
More information about the Web-SIG