[Web-SIG] Other kinds of environment variables

[Mark Nottingham]

On Aug 26, 2004, at 6:42 PM, Phillip J. Eby 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.

Digest auth sucks much less, and also uses REMOTE_USER.


>> * 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``.
> """

Looks good.


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

OK, I'll take that as a challenge :)  I agree that it doesn't make 
sense to put this onto the critical path for WSGI getting into a PEP.


> Other areas that need to be addressed within HTTP/1.1 probably also 
> includes things like byte ranges.

Ah, yes.


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