Re: HTTP router point-of-view concerns

On Jul 13, 2013, at 10:11 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> In message <22115082-53F8-433C-9497-755800803B93@checkpoint.com>, Yoav Nir writ
> es:
> 
>> This thread has forked to discussing session management. I'd like to call 
>> your attention to the fact that in the past, this working group was consider
>> ed too busy with HTTP/2.0 to spend time on things like session management
>> or HTTP authentication schemes. For this reason it was suggested that the 
>> WebSec working group work on session management. 
> 
> Then just call it a "flow-routing-label" here, and let WebSec figure
> out for themselves that it can also be used as a session identifier.
> 
> There's no need to let procedural overhead get in the way of good ideas.

It's more than procedural. Whatever is wrong with the use of cookies to manage sessions is wrong in HTTP/1.x just as much as it is in /2.0.

There will come a day when we can say that HTTP/1.1 is only for legacy applications, and that it's fine to make sweeping changes only in HTTP/2.0 (or perhaps introduce them in HTTP/3.0). That day is not today, and if we're going to fix it, we might as well fix it in 1.0 as well.

Your proposal (http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/0284.html) includes prohibiting cookies on HTTP/2.0. This directly conflicts with this working group's goal of creating a protocol that is a drop-in replacement for HTTP/1.1. If I have a web application running on an Apache server that makes use of cookies to handle session management, I can't just install modhttp2, add a line in the config file and have everything continue to work. I would have to do significant work to make my website work with HTTP/2.0. If we accept your proposal, this would be an impediment to deploying HTTP/2.0.

So I think that a new session management scheme is something that should be orthogonal to HTTP version, and should be a separate work item. This is regardless of whether that work item belongs in httpbis or in websec. 

It should also be noted that you're missing two requirements from session management:
 1. That the session be bound to an authenticated identity.
 2. That users won't have to authenticate too often.

This is easy to accomplish with cookies: you set the cookie when the user authenticates, and you allow it to persist for as long as you want. I'm not sure how this can be accomplished by a session identifier chosen by the UA.

Yoav

Received on Saturday, 13 July 2013 20:25:05 UTC