W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: HTTP router point-of-view concerns

From: Michael Sweet <msweet@apple.com>
Date: Fri, 12 Jul 2013 08:40:48 -0400
Message-id: <C0C65ACC-673E-4E07-B2D0-B84723755E6F@apple.com>
Cc: Mark Nottingham <mnot@mnot.net>, Sam Pullara <spullara@gmail.com>, James M Snell <jasnell@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC