[Web-SIG] and now for something completely different!

Rene Dudfield renesd at gmail.com
Thu Aug 18 05:43:38 CEST 2005

Some more requirements for sessions can be found at the php page on sessions.

Hash function declaring:
   Chosing eg md5/sha.  Also by using a distributed hash function you
can easily route the request to a specific web server.  So with one
rewrite rule you can have your scalable sessions/session affinity. 
The function could simply append the number 1-100 in front of session
id which relates to a particular webserver.
tag rewriting.  
    ie.Which tags to do rewriting in.  eg where it appends
?SESSIONID=ABCFED938743523 to your output html.

url_rewriter.tags  string

    url_rewriter.tags specifies which HTML tags are rewritten to
include session id if transparent sid support is enabled. Defaults to


... and now for all the arguments pro Session rolled up into one paragraph.

Taking load off the database server(with sessions) is a way to make an
application more scalable.  Often the database server is the
bottleneck of the web app.  Being able to move some load to the
client, or the webservers is a good option to have.  Being able to not
use 2 tiers is also what people may want.  In this way sessions allow
you to scale up, and down.  Sessions allow you to do a lot of jobs
which databases are not needed for.  Sessions are also more reliable,
and secure than cookies.  Cookies may not be enabled on the browser,
and storing some stuff on the client side in the clear, or even
encrypted is dangerous.  Sessions are understood by a large amount of
php/java/perl/apache people.  Lots of the python web frameworks have
implemented sessions too.  This means sessions will be used.  So
making a good working implementation of sessions that everyone can
share would be double plus good.

On 8/18/05, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:33 PM 8/17/2005 -0400, michael bayer wrote:
> >its usually not my experience either, and I have rarely written any kind
> >of app that uses sessions.  99% of everything I've done relies upon
> >browser state as well.  although despite my being there "when the web was
> >won" in 95, I am hesitant to call myself a RESTFUL developer...to me, REST
> >seems to be taking some common sense ideas and turning them into some kind
> >of rigid ideological crusade, which is just as bad as all the other
> >ideological crusades we "web winners" had to fight with IIS and active
> >server pages, EJB, UML, SOAP, etc.
> I agree; I just find it useful to use the REST banner because before that
> word came around, there was nothing to call the approach.  I'm a pragmatic
> RESTee in that browsers don't do PUT and DELETE so POST is pretty much what
> we have to work with for human-usable applications today.
> >a document editing system is also a good example of where objects need to
> >be persisted in two different scopes, i.e. a session-scope as well as a
> >permanent scope.   I dont really think a session has anything to do with a
> >"physical three-tiered model".   physically, it can be whereever you
> >want.  i just think its advantageous from a conceptual point of view.
> I don't object to server-side objects that are session-specific; I object
> to the "bag of arbitrary objects" session interface, that is typically
> stored in a web tier or middle tier.  Those are two distinct sins that are
> usually coupled in what most people think of as "a session".  When I say I
> consider sessions harmful, it's specifically those two characteristics of
> the common meaning of the term.  I'm not saying that I think there's no
> such thing as a "session" in the sense of a browsing session.  Shopping
> carts would be pretty hard to do, for example, without session-specific
> server-side objects.  I just think that storing the shopping cart data in
> anything other than your application database is almost certainly a Very
> Bad Idea.

More information about the Web-SIG mailing list