[Web-SIG] Other kinds of environment variables
Mark Nottingham
mnot at mnot.net
Fri Aug 27 05:44:38 CEST 2004
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/
More information about the Web-SIG
mailing list