[Web-SIG] Logging the authenticated user (was Re: Bowing out)

[Phillip J. Eby]

At 10:47 AM 2/8/2006 -0500, Clark C. Evans wrote:
>On Tue, Feb 07, 2006 at 09:20:38PM -0500, Phillip J. Eby wrote:
>| At 08:22 PM 2/7/2006 -0500, Clark C. Evans wrote:
>| >I absolutely love wsgi.response_filtering, only I feel that it should be
>| >a *mutable* listing of the headers that the server should strip.  If
>| >the list is not present, then response filtering is not available. In
>| >particular, I think that requring 'X-Internal-' is not quite explicit
>| >enough and, at the same time, too limiting.
>|
>| I don't understand what you want to do with this.  Can you be more
>| specific about what's limiting and how, not to mention what you expect
>| to do with this mutable list?  Thanks.
>|
>
>I think it is unnecessarly limiting since you might want the server to
>filter (not send to the client) other headers, such as something like
>the Meter header defined in RFC 2227.  This seems like a generally
>useful feature; I don't see the need to restrict it to only headers
>starting with 'X-Internal-'.
>
>At the same time, explicitly listing the headers you wish to filter
>isn't that much of a burden -- and actually helps document (paste.lint
>could, for example, issue warnings of all 'X-Internal-' headers that
>arn't listed for filtering; this could be used to catch spelling errors).

My concerns about this are that it introduces unnecessary coupling and 
doesn't reflect the intended use case, which is for allowing internal 
communication between WSGI servers and applications.  These are all 
internal headers, and I don't see how or why 'Meter' would be used with this.

It also seems to me that the spellcheck use case would be better handled by 
defining a 'wsgi.known_internal_headers' provided by the server to the 
application, so that the application can determine whether a particular 
piece of functionality is supported.  In other words, I still don't see the 
purpose of having a mutable; the environ key is for the server to 
communicate to the app, not the other way around.  (Which is done by the 
headers themselves.)