Re: HTTP router point-of-view concerns

[Christian Parpart <[e-mail]>]

On Fri, Jul 12, 2013 at 2:40 PM, Michael Sweet <[e-mail]> wrote:

> Then just add the User-Agent and Server values to the settings frames the
> client and server exchange?
>

if it would be *that* simple, then dont' forget the cookie and the
user-agent.


> Sent from my iPad
>
> On 2013-07-12, at 7:44 AM, Poul-Henning Kamp <[e-mail]> wrote:
>
> > In message <[e-mail]>, Mark
> Nottingham wri
> > tes:
> >
> >> This has been brought up a number of times. I think what we need is a =
> >> concrete proposal *with* a detailed plan for a workable transition to =
> >> the new mechanism -- which seems to be the (or at least one) sticking =
> >> point whenever this comes up.
> >
> > I have given a concrete example multiple times, it's very simple:
> >
> >    The client always sends along a session-identifier of N (128?)
> >    bits.
> >
> >    If the first bit is zero, this is an anonymous, transient
> >    session, not (to be) associated with any other session.
> >
> >    If the first bit is one, this is a persistent session
> >    identifier, which the server can use to look up any relevant
> >    state or information from previous instances of this
> >    session, in its local database.
> >
> >    This replaces the Cookie: and Set-Cookie: headers, which
> >    SHALL NOT be sent in the HTTP/2.0 protocol.
> >
> > Advantages:
> >
> >    We get a fixed size session-identifier for HTTP routers to
> >    use for flow-routing.
> >
> >    We get an actual (client controlled) session-concept, rather
> >    than all sorts of ad-hoc simulations with cookies.
> >
> >    Data with privacy-concerns are stored on the server not on
> >    random clients the user happens to borrow or use.
> >
> >    The overhead of encrypting and signing the data in cookies
> >    is avoided, since they are stored on the server side where
> >    nobody can fudge them.
> >
> > Backwards compatibility:
> >
> >    It should be obvious that simulating the Cookie concept for
> >    framework compatibility on the server side is a trivial
> >    matter of programming:  Rather than send set-cookies, write
> >    them to a database, indexed by the session-id.  Rather than
> >    receive Cookie: headers, look them up in the database.
> >
> > There, solved.
> >
> > Again.
> >
> > --
> > Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> > [e-mail]         | TCP/IP since RFC 956
> > FreeBSD committer       | BSD since 4.3-tahoe
> > Never attribute to malice what can adequately be explained by
> incompetence.
> >
>
>