[Web-SIG] Standardised configuration.
py-web-sig at xhaus.com
Mon Sep 6 15:30:00 CEST 2004
>> I originally thought that option B was the best, but now I think
>> differently. And from what I read from your post, Paul, I think
>> we're in agreement.
> Are we? ;-) Certain things like sessions are most likely to be
> configured in the server environment. In Tomcat, for example, that
> would be in one of the XML configuration files, but for something
> like Apache/mod_python it would be nicest to use httpd.conf or a
> related file, and Webware and Zope store sessions in their own
> particular way - note that Zope uses its own special mechanisms
> which might not correspond exactly with the conceptual model you
Ah, now we're getting somewhere.
I think that session handling is an excellent example against which to
have this discussion. Note however that I am *not* advocating
standardising session management under WSGI.
J2EE session handling is generally a huge PITA, primarily because the
base unit of session management is the servlet context, i.e. every
servlet context gets its own "session space". For example
'/forms' may map to one session space, while
'/news' may map to a different session space.
Any given user may have multiple sessions on a server, depending on the
number of servlets they have interacted with. It is generally not
possible, except using container specific methods, to have a single
"uber-session" which concentrates all user session data into a single
object. This "hierarchy problem" makes it difficult, and extremely
container-specific, to manage a single set of users across a set of J2EE
Most J2EE containers support both cookies and URL rewriting for session
management, i.e. if the user-agent has cookies disabled, then all urls
are rewritten to contain sessions IDs. Which means that the url
rewriting algorithm has to be aware of multiple servlet contexts, and
rewrite local urls to contain the session ID which is specific to the
Some J2EE containers support a "Single Sign On" facility, where the
container manages the multiple session objects on the applications
behalf, and makes it easy for the user (but not the programer) by only
making them sign on to a server once. Tomcat does this using an extra
cookie, the SSO cookie, which is transmitted to user-agents *as well as*
the per-servlet cookie, i.e. the user-agent receives two cookies from
the container. Worse, the Tomcat Single-Sign-On facility does not
support URL rewriting: the user-agent *must* have cookies enabled in
order for single sign on to work. Which sucks.
I think that if WSGI applications were to rely on the local
platform/container session management facilities, it is extremely
unlikely that they would be portable. It's difficult enough to get
coherent cross-servlet session-handling working on J2EE when writing in
java, as these pages show
Imagine the complications if the application code were originally
written to work with say, WebWare under cpython?
To me, session handling is one of those things that is done in so many
different ways by so many different platforms/containers that it is
impractical to achieve application portability once a particular
methodology has been chosen.
So, IMHO, session handling is one of those "should be simple" areas of
web programming that gets horrifically complicated when trying to move
applications between platforms/containers: in fact I'd go so far as to
say the multiple session handling techniques is one of the primary
reasons why the python web world is currently so fragmented: every
framework author thinks they know best: although some do it much better
than others. I like webwares method of using URL path parameters, with a
auto-refresh if a request is received that doesn't contain a session ID.
But IIRC, this method is quite Apache specific, and requires
modification of the Apache httpd.conf to get working. I could be wrong
It is important to note that I am *not* advocating standardising session
management under WSGI: far from it. But what I am advocating is trying
to make it as easy as possible for session-handling middleware
components to be as portable between WSGI servers as possible. WSGI, as
it currently stands, makes it far easier to do this than any other
approach: I'm just trying to foresee and eliminate the last few % that
stands in the way of 100% portability.
More information about the Web-SIG