<p><pre><code> In my view, HTTP/2.0 should kill Cookies as a concept,
and replace it with a session/identity facility, which makes
it easier to do things right with HTTP/2.0 than with HTTP/1.1.
</code></pre>
count me in. Cookies are a huge waste of bandwidth and freaking annoying here in Europe as you cannot visit a site anymore without being warned you are about to receive yet even more cookies.
What really frustrates me about HTTP as a protocol is that it provides the beginning of a framework to do session management using the WWW-Authenticate headers, but it's ignored because the site can't provide a good UX. Instead we end up with phishing, terrible login forms and poor security when people reimplement session management in Cookies.
This has been going on for a long time and nothing got done. HTTP-NG started in 1997. If you try to boil oceans, you get nothing.<p>The recent why SPDY is succeeding is because it is not trying to solve every problem and grind every axe.
A good analysis but somewhat dated. It has been established, for instance, that with a compatible SSL lib and TLS NPN support SPDY/HTTPbis can be supported on the same socket and port as HTTPS. With that said I really like what PHK has to say about "HTTP routers".
Well transmitting text never seemed really very much interesting.<p>http was nice because it was easy for software programmers to write apps that could work over http, because no binary protocol was involved: reading ASCII strings is never complicated. It was good for a growing industry.<p>Now most browsers are open source, why can't the IETF work out a binary protocol ? Bittorrent is binary, and it's awesome and it's used. Why can't any browser work out a binary protocol ? Truly dynamic pages over the network ? Why not ? I'm sure some software already does that. Make one open source, make it work on firefox or chrome, I guess things would start to light up.
I wonder if header compression is primarily to allow for ubiquitous, large cookies.<p>Cookies were originally and with few exceptions remain a hack to try to add state to transactions that were not intended to be stateful.<p>If indeed the header compression is driven by the growing prevalence and size of cookies, then HTTP/2 is an effort to accomodate a hack. Not very interesting.<p>Some hacks that find their way into RFC's are difficult to remove because the transition process would be unreasonably expensive, like replacing the "sophomoric" compression scheme in DNS with something more sensible like LZ77 (credit: djb).
I guess we might see some passionate arguments by web developers about the great expense of removing cookies from the HTTP standard and replacing it with a session facility, but I think the (long term) benefits easily outweigh the (short term) costs.
Some discussion from last year, fwiw: <a href="https://news.ycombinator.com/item?id=4253538" rel="nofollow">https://news.ycombinator.com/item?id=4253538</a>
In reading this a protocol that supports two initial statements upon connection/negotiation as follows...<p><pre><code> s: http/2.0 {SERVER INFO}
c: connect host/ <-- no path
s: OK {server-cert/key}
-- all futher requests encrypted against public key/cert
c: session-start {client key/cert}
s: SESSION: {session id} ({domain1},{domain2},...)
c: (COMMAND|get|put|post|delete) {PATH}
s: OK
or
DENIED ### (reason) <-- response code & reason
or
REDIRECT host/(path) <-- if the file is physically on another backend
c: {OTHER REQUEST HEADERS START}
</code></pre>
after a session is started, the client may make other requests<p><pre><code> s: http/2.0 {SERVER INFO}
c: connect host/{path}
s: OK {server-cert/key} or DENIED ### Reason
-- all futher requests encrypted against public key/cert
c: session-join {SESSION_ID} {client key/cert}
s: OK or DENIED...
c: {COMMAND} {path}
</code></pre>
from there, the "session_id" can be a key for server-side value storage/lookup, etc... sent over the encrypted channel
> Our general policy is to only add protocols if we can do a better job than the alternative, which is why we have not implemented HTTPS for instance.