[Web-SIG] Standardised configuration.

[Alan Kennedy]

[Phillip J. Eby]
> Just to throw another thought in here, keep in mind that one could write 
> a "cookie consolidator" WSGI component that would send its own 
> session-management cookie to the client after removing application-sent 
> cookies from the responses and saving them somewhere locally.  When a 
> request comes in, the "cookie consolidator" would read its own cookie 
> from HTTP_COOKIE, and then add the stored cookie data before passing it 
> on to the application.  So, from the app's point of view, it's as if all 
> the cookies are going to the client, but in reality there's only one, 
> with the rest of the data stored server-side.
> 
> One could presumably also extend this cookie consolidator to manage 
> other kinds of session keys as well, such as ones embedded in the URL.  
> Or, for that matter, you could write one that embeds its session key in 
> the URL instead of in a cookie, but still makes it look to the 
> application as if cookies are being used.

That's an excellent idea, and could solve the problem of multiple 
session handling techniques very well, and in a portable manner.

However, it would only work for WSGI middleware components that are 
above that session component in the middleware stack.

If the application administrator had configured session management in 
the platform configuration file, e.g. tomcat server.xml, then that 
session management would be run *after* the entire WSGI middleware stack 
had completed.

But that's not a problem according to my view of things: avoiding 
platform managed sessions is the whole point.

Were I running a WSGI middleware stack inside Apache or Tomcat, I'd want 
to disable the "native" session handling completely, and instead take 
care of it entirely within the WSGI stack.

Regards,

Alan.