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