[Web-SIG] Other kinds of environment variables

[Phillip J. Eby]

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 
yet.

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" [3]_, 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.