Hello, everybody. I just got the time to read PEP-444 and I wanted to propose the addition of a feature: The ability for servers, gateways or middleware to get metadata about the response.
>From time to time I find myself in situations where I wish there was a way to pass arguments to WSGI middleware on egress, and HTTP response headers (e.g., "X-My-Argument") are the only option but they can only take strings. I know some people don't like "mandatory" middleware because they believe that applications must be able to work without them, but the truth is that they are pretty common, and without a way to segregate our response's metadata and HTTP response headers, the former would make it to the client in the absence of the expected middleware. The third disadvantage of this approach is that the middleware has to iterate over all the HTTP headers until it finds the one it's looking for -- if it's present. The environ dict can't be used. First, it's semantically incorrect as it's meant to represent the request. And second, a middleware could have replaced it. The following two examples come to mind, and a third one in coming in a separate email to this mailing list: Example 1: repoze.who's X-Authorization-Failure-Reason ====================================================== One of the repoze.who built-in plugins ("form") allows applications to pass an argument on egress. This argument is a user-visible message on why he's been asked to log in (e.g., the session expired, he's attempting to access sensitive information anonymously), and it's expected to be in the HTTP response header "X-Authorization-Failure-Reason". When the application asks the user to authenticate (e.g., returning a 401), this plugin intercepts that response and redirects the user to the login form and, if a reason was set by the application, it's put in the query string so that the message can be displayed next to the login form (for example). Example 2: wsgi.file_wrapper ============================ In the current draft for Web3, file wrappers are left out because "the old system of in-band signalling is broken if it does not provide a way to figure out as a middleware in the process if the response is a file wrapper". This problem would be solved with response metadata. ============================= The application callable's signature would then look like this: status, headers, body, meta = application(environ) And "meta" would be a dict object. What do you think? Cheers. -- Gustavo Narea <xri://=Gustavo>. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | _______________________________________________ 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