- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 26 Jun 2012 17:29:55 +1000
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: William Chan (???) <willchan@chromium.org>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Howard Dierking <howard@microsoft.com>
On 26/06/2012, at 4:41 PM, Poul-Henning Kamp wrote: > One of the biggest deficiencies in HTTP/1.x is the lack of a "session" > concept, which lead to the Cookie-Hack with all its pessimizing and > privacy-violating issues. > > Even if used right (one cryptosigned session-identifier, all actual > data stored serverside) it has the sideeffect of blanket disabling > caching. > > HTTP/2.0 should do better. I have a hard time seeing how that's in the current scope of discussion. Part of the reason that this sort of thing is out of scope is that it's a big rat hole, and the more we take on redesigning, the less likely we'll be able to ship something and have it deployed. New features can and should be layered onto HTTP independently of the version identifier, which is for identifying the wire protocol, not fine-grained feature negotiation. See <http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.1>: > The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. ... and RFC2145. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 26 June 2012 07:30:30 UTC