Fwd: Introducing a Session header...

This moved off list unintentionally...

---------- Forwarded message ----------
From: James M Snell <jasnell@gmail.com>
Date: Tue, Jul 17, 2012 at 4:48 PM
Subject: Re: Introducing a Session header...
To: Martin Thomson <martin.thomson@gmail.com>


This, without question, would be the right approach... assuming we can
successful move people away from using sessions as a whole. The main
motivation for me on this is making it more efficient to package and
process the bits necessary for basic header operation. If we can drop
session-based routing from the picture, then fantastic.

(While we're at it, can we also eliminate routing based on the request-uri?)

On Tue, Jul 17, 2012 at 4:44 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 17 July 2012 16:27, James M Snell <jasnell@gmail.com> wrote:
> > I certainly do not disagree. So, given this strawman, and assuming the
> goal
> > is to constrain crappiness and make things easier for http routers to do
> > their job in the process, what would be a better approach to start from?
>
> I think that Ian has it right.  The most sensible approach is to avoid
> entering the quagmire altogether.  By necessity, we will be able to
> transport cookies and people with therefore continue to use them.  For
> everyone else, don't encourage new abuses of the protocol.
>
> BTW, I'm seeing moves to avoid and even remove stateful routing of
> HTTP.  I work with Azure a lot now and the load balancers there
> purposefully round robin requests with no sessions, cookies, or any
> sort of stickiness.  It's a bold move, the right move, and not one
> that they would have gotten away with 5 years ago.  The world is
> slowly learning.
>
> --Martin
>