Re: HTTP router point-of-view concerns

[Patrick McManus <[e-mail]>]

cookies and user agents, while very redundant, are not 100% consistent
between transactions. Especially in proxying scenarios, but other places
too.

And even if we removed those, a request header would still be ~300 bytes -
which is just too big to support the many dozens of subresources that
commonly make up a page today in one rtt.

I understand some of the frustration, but this is something we've seen work
and imo is necessary to enable the fundamental muxxing changes http/2
presents.





On Fri, Jul 12, 2013 at 8:47 AM, Christian Parpart <[e-mail]> wrote:

> 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.
>> >
>>
>>
>