Re: HTTP router point-of-view concerns

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


Sent from my iPad

On 2013-07-12, at 7:44 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> In message <CD9E163F-1225-4DA8-9982-8BDBD16B1051@mnot.net>, 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
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
>

Received on Friday, 12 July 2013 12:41:38 UTC