[Web-SIG] Standardised configuration.
py-web-sig at xhaus.com
Mon Sep 6 16:38:26 CEST 2004
[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
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.
More information about the Web-SIG