On Tue, Jan 24, 2006 at 11:33:56AM -0500, Phillip J. Eby wrote: | > I think this is way too specific; it doesn't address the general | > problem: how do you pass information back up the middleware stack.
| There is no "general problem" which anyone is trying to solve. The use | case requested by Jim and Stephan is quite specific. Yes there is; it is passing information from applications back to middleware (or the server), you even talk about it yourself: | I'm now more convinced than ever that the right place to | communicate information back to the server is via response | headers, and that's how this use case should be addressed in | WSGI 1.1, as it maintains the functional composition of middleware If this is the solution, great. However, I really don't like the ``environ`` options out there /w mutable objects. Can you please then specify a *general* mechanism for headers that won't be sent to the client? My server needs to know which ones to strip. On Tue, Jan 24, 2006 at 10:53:53AM -0600, Ian Bicking wrote: | Jim Fulton wrote: | > Phillip J. Eby wrote: | >>I'm pointing out that the use case under consideration isn't specific | >>*enough* yet. Do people's log files support unicode? Do the | >>authentication systems? This hasn't been made clear, and it should be. | > | > I agree. I think we should be guided by the common log file format. | > Log data are written to files and are thus not unicode. The user | > info is *just* documentation, so it is really up to the app what to | > show imo. Further, because the common log file format is space | > delimited, the user info cannot contain spaces. | | It is up to the consumer to handle any unicode, and to maintain the | integrity of their log format regardless of input. I second Ian's opinion. I have to log Russian user-names and web-pages, internally I use Unicode strings; and when writing to common log file format, I simply urlencode the string. This takes care of spaces and non-ASCII code points. Thus, the WSGI specification should not restrict the character set, since some other logging middleware might want to use XML(UTF-8) or write each access to a database that is unicode aware. The value should be *any* python string object; let the logging module determine the type and encoding and handle it as needed. On Tue, Jan 24, 2006 at 12:35:48PM -0500, Michal Wallace wrote: | I think you guys are trying to solve this at the wrong level. | This problem should be handled by the web server itself. People are writing features like this as specific middleware components so that you don't have a bloated web-server. | Maybe I just don't understand why this is important. Can | someone (Jim) explain why this is a requirement in the | first place? Well, the general problem is how to communicate information from applications back to the middleware or server. This is one use case; there are others, I am sure. On Tue, Jan 24, 2006 at 07:31:35AM -0500, Stephan Richter wrote: | > Why not ``wsgi.context`` or something like that which defaults to | > an empty dictionary. ?Then you can put what ever you want in it; | > ``wsgi.user`` just seems to be a bit too specific. | | But if you use a dictionary you need to specify all allowed keys. Fine, use REMOTE_USER as this is a CGI standard. | The twisted guys and us have thought about other possible data for | logging and we could not come up with any. If you have real use cases | for other data, please let me know. Depends on the logging level; 0. Trace messages 1. The database instance name used 2. A sequence of SQL queries executed 3. Files that were created by the request etc. I can think of a lot of things I might want to log (and in fact do log); that said, I'm not interested in this specific application -- I want the general case spelled-out. How do I pass information from the application back to the middleware reliably? | > Why cannot it just accept a Python string? ?You can always check | > if it is Unicode or not. | | Because encoding might be arbitrary. It has to be clearly specified in the | specs what to expect. It's very easy for the logging module to check what it has and act intelligently. We arn't using C89... Best, Clark _______________________________________________ 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
