[Web-SIG] Web3 proposal: Response Metadata
Gustavo Narea
me at gustavonarea.net
Tue Sep 28 23:39:00 CEST 2010
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 |
More information about the Web-SIG
mailing list