At 12:02 PM 2/7/2006 -0500, Stephan Richter wrote: >BTW, did we reach a conclusion on the user logging issue. We really, really >need to solve that somehow. Anything you can come up with is fine by me; I'll >trust you do the right thing.
As I mentioned, you can do this right now by offering and documenting an extension API. You don't need a modification to the PEP to do this; it's sufficient for you to get together with the authors of the web servers you care about and hash out a working agreement. To get it into the 'wsgi.*' namespace and included in the PEP as a "standard" optional extension, the bar is a bit higher, and it does require coming to some resolution about the remaining issues. If I recall correctly, the question of which side (server or app) should be responsible for encoding issues was the remaining open item, aside from the name that should be used for the extension API. Also IIRC, Ian Bicking had proposed that the server should be responsible for making sure that what it writes to the log is in a valid format for that log. I'm inclined to agree, and think we should use a name like 'wsgi.set_authenticated_user_name', with the API allowed to be called multiple times. For future versions of WSGI, I'd prefer to send this kind of thing in response headers, since that would preserve functional composability better. Indeed, I'd prefer to do it that way now, but too many people have objected to this as a security risk. OTOH, an easy way to fix that would be for us to define a 'wsgi.response_filtering' key that means the server will drop any 'X-Internal-Foo' headers. You can then simply avoid generating any internal communication headers unless the server promises to fix them. And, as a side effect, this would close the encoding issue by definition; the format of response headers is already dictated by the WSGI and HTTP specs. So, if there are no objections, I propose that we: * Add an optional 'wsgi.response_filtering' key to the spec. If its value is present and true, the server promises to prevent 'X-Internal-*' headers from being transmitted. * Add an optional 'X-Internal-WSGI-Authenticated-User' header to the spec, that indicates the authenticated user name. This should only be inserted into the response headers if 'wsgi.response_filtering' is in effect. * Require that any user-defined X-Internal headers include a product name, e.g. 'X-Internal-Zope-Foo', to avoid conflict with WSGI-defined or other products' user-defined headers. This would all be placed under a new section entitled "Internal Response Headers" and defined as an optional extension. Any thoughts? _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com