[Web-SIG] Web3 proposal: Response Metadata

[Gustavo Narea]

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 |