[Web-SIG] Communicating authenticated user information

[Clark C. Evans]

I'm not convinced that we shouldn't just require WSGI middleware
to forward on the *exact* same ``environ`` as it receives.

On Mon, Jan 23, 2006 at 03:29:32PM -0600, Ian Bicking wrote:
| Paste already does this, for the N subrequest method.  This is done at 
| least in paste.cascade, where we retry the request several times until 
| something responds with a non-404.

Yes; this is exactly the sort of edge cases that I think will elude just
about any "general" solution.  How would Phillip's recent suggestion,
for example, a ``wsgi.log_username`` work in this situation?

Assertion:

  If a WSGI middleware component _isn't_ passing on the actual
  ``environ`` given by its parent, then it is an edge case where
  this problem can't be solved anyway.

| I suppose you could update the one-and-only environ from a copy 
| you made before sending the request on.  But anyway, it doesn't do that.

Yes, you could for this case _copy_ the ``environ`` and then when
one of the cascade applications returns, you can update the 
original ``environ`` with the saved copy. 

Suggested Wording:

   A WSGI Middleware component (that is, one that receives a 
   request and forwards it on to another component) must forward 
   on the *exact* same ``environ`` dict that it received.

| I'd like to do this same thing (N subrequests) sometime in the future 
| for server-side HTML Overlays.

The above restriction won't hurt these use-cases (which you must
be careful about anyway), and it addresses the current issue:
how does one pass information back up the call chain.

Best,

Clark