Phillip J. Eby wrote: > 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?
Sounds good to me, and wsgi.response_filtering seems to address the backward compatibility well. It would be easy, for instance, to apply the filtering in the logging middleware if the server was not already filtering the response, and set the key to represent that the filtering was in place. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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
