
HTTP 2.0 - abhshkdz
http://tools.ietf.org/html/draft-ietf-httpbis-http2-04
======
Aloisius
Oh wonderful, it appears to use SPDY-like header compression. Why don't we
just create a new compression algorithm and predefine common HTML tags and
words to improve compression of the response body too! But we shouldn't base
it on any known compression scheme and only use it for the case where the
content length is less than 220,498 bytes but more than 8,494 bytes to
optimize the behavior of today's more common MTU settings for PPPoE in
Scandinavian countries minus of course the most common size of compressed
headers today. It will be particularly optimized for the kind of responses
Google sends back to minimize their own server load and common adwords will of
course be included in the predefined list of compressed tokens.

/sarcasm

What happened to simple protocols? Seriously, per-hop flow control (which
works best with which of the dozen version of TCPv4 or TCPv6 flow control?)?
TCPv4-like framing with weird limits (16383 bytes)? Keepalives/Ping? Truly
ridiculous specialized compression for headers which ignores the role of HTTP
proxies? QoS?

Why not just implement the whole protocol over a raw IP connection and stop
pretending like we're operating in layer 4+? I get that multiplexing is
difficult without flow control, but good lord does this thing look
overdesigned for what few benefits it offers over HTTP/1.1.

~~~
nly
I can't help thinking some of the pain could be resolved if we had a reliable
datagram protocol between UDP and TCP. Delimiting a TCP stream to create a
messaging protocol is already suboptimal and error prone, and it's the root
cause of the head-of-line blocking problem experienced by HTTP ('fixed' in
SPDY).

~~~
Camillo
There can be no new layer 4 protocols due to NAT. You have to use either TCP
or UDP.

~~~
nly
So we can move from IPv4 to IPv6 but not introduce a new transport because of
NAT? Hmm...

~~~
wmf
The IPv6 transition is not going that much better than SCTP. So many people
have v4-only home routers that they have no plans to ever upgrade.

~~~
mavhc
Most people have a free router from their ISP, the ISP will just send out new
ones

------
samwillis
I understand the motivation to going to a binary protocol for a SPDY inspired
HTTP 2.0 but I would have liked to see an ascii based protocol similar to what
jgrahamc proposed last year [0]. I thought it was a much cleaner protocol to
read and understand, and much more in tune with what the web is supposed to
be. Why not keep the clever binary stuff separate in SPDY, endorse it though
the IETF and keep HTTP ascii?

[0] [http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-
pr...](http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-
protocol.html)

~~~
peterwwillis
This idea is bad for a couple reasons.

First, ASCII is inefficient. People don't interpret HTTP, computers do. Web
servers and browsers. People only look at HTTP when they want to troubleshoot
without any tools. With real tools, you can find out what's broken much
quicker. And there's plenty of things you can miss without a real HTTP
interpreter. Most hackers prefer to think of themselves as wizards that can
spy 0's and 1's and tell you what the weather is. It doesn't make for a
_better protocol_ , though.

Second, we can already break HTTP responses up in multiple parts, using a
novel idea called "multipart". It sucks and nobody has used it since HTML/JS
found new ways of providing content.
[http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html](http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html)

Third, it's a hack. If you want to improve the protocol, improve the protocol,
don't just hack onto it to make it do what you want. I could make a horse and
buggy go 60mph, but would it be a good idea? How about just designing a better
buggy that is intended to go 60mph?

Fourth, fixed-length records are the _wave of the future!_ It solves crazy
problems like header injection and request integrity checking. Moreover, it
makes for simpler, more efficient parsing of requests.

Fifth, redundancies introduced from the beginning of time need to go away,
like terminating every record with "\r\n", or passing the same headers on
every single damn request when once should be just fine for a stream of
requests. Little inefficiencies like this don't go away if you just hack onto
the same old protocol forever.

Sixth, the flow control improvements can make different applications more
efficient by both not having to hold state of where and when traffic is coming
and improving flow across disparate network hops.

Seventh, as to a general question "why use binary when we can compress stuff",
what is smaller: a string of bits, or a compressed string of digits? Add to
this that every header could have a 32-bit identifier (4 bytes) and you've got
more efficient compression than gzip. Of course, most people would argue that
you don't save enough time or bandwidth or cpu cycles to make a difference,
but it _would_ make for easier-to-write parsers, which would make working with
the protocol in general more attractive. But then you have your binary-
detractor-wizard-hackers and the whole conversation becomes an infinite loop.

~~~
romaniv
The same arguments can be applied to HTML, CSS, JSON, RSS and so on. I fail to
see the crucial difference between those and HTTP. Or would you say the web as
a whole should be binary?

 _Fifth, redundancies introduced from the beginning of time need to go away_ I
wholeheartedly agree with this, but it doesn't automatically warrant binary
encoding.

Human readability is a huge bonus in any protocol or format. Not because
normally people read those protocols, but because people read ASCII and
therefore they have good tools to work with ASCII.

~~~
peterwwillis
...? Seriously? You don't see the difference?

HTTP is a layer 7 communication protocol. HTML/CSS are markup languages for
designing an interface. JSON is a data interchange format. RSS is a content
syndication format.

They are all wildly, vastly different. The only thing they have in common is
they're all ASCII. If anything, you're making my argument for me: a
communications protocol is not a format for displaying documents, it is a
language for communicating machine instructions to network applications.
Historically they have always been binary because _it works better that way_.

Your argument that "people can read ASCII, so ASCII is good" leaves out a
couple points. Like, human beings do not read an HTTP statement, go into a
file folder, bring out a document and present it to their computer. It's the
other way around.

Really this just reflects a strange phobia people seem to have. Like your
brain is tricking you into thinking you'll lose something by not looking
directly "at the wire".

When you look at HTTP headers, 90% of the time you're actually looking at a
pre-parsed, normalized set of fields. If you look at a raw packet dump, the
whole message may not show up in one packet; you may have to reassemble it,
which means parsing. If you have multiple requests in one connection, you have
to find the end of the last request, which means seeking through the stream;
seeing requests broken down individually means a tool already parsed them.
Firebug and wireshark and other tools all take care of the automated, machine-
operated work for you.

And what's left? What do you have to do with HTTP, really? Apache rules?
They'd stay human-readable. Application testing? We use proxies that handle
it, and APIs for client/server programming. Firewalling? Handled by tools and
appliances.

Stop giving me the blanket "ASCII is great for everything" excuse and tell me
one thing, one single thing, that only humans are able to do with HTTP using
their eyes without a tool. But you don't have to, because that's impossible:
HTTP is _not for humans_.

~~~
romaniv
_Apache rules? They 'd stay human-readable._

I look forward to servers having different text representation of the same
binary headers in their config files.

 _tell me one thing, one single thing, that only humans are able to do with
HTTP using their eyes_

You're missing the point.

No one writes HTML manually anymore either. People generate it using tools
(string processing tools in a language or templates) and read it using
browsers. Heck, even Notepad++ is a tool, but a generic one.

If you want, you _can_ generate all your HTML using DOM. But almost no one
does that, because DOM tools are clumsy, while text-based tools are easy to
use.

~~~
peterwwillis
You're actually still arguing for my point instead of against it.

If no one writes HTML manually anymore, then we have no need for it to look
like English when the computer interprets it! We can compile the HTML down to
bytecode and have it be interpreted much quicker by the computer, which won't
have to do the job of lexing, compiling, assembling, etc. Here, two steps
would be eliminated immediately, resulting in increased speed and more
efficient storage and transmission:
[http://www.html5rocks.com/en/tutorials/internals/howbrowsers...](http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#Main_flow_examples)

For that matter, if it's generated by tools, and we use programs designed to
interpret and decipher and color-code it, all of that can happen without it
being in English!

On top of that, you missed when I said HTTP is a communications protocol. Ever
seen the movie The Matrix? Know how the sentinels would sometimes look at each
other and make scuttling noises, then shovel off somewhere? They weren't
speaking English ASCII. They were speaking a binary communications protocol.
Know how I know? BECAUSE MACHINES AREN'T HUMANS! It would be absolutely
moronic for them to speak English to each other. It would be like dogs saying
the English word "bark" instead of just barking. Completely unnecessary and
crazy. But that's what an ASCII communications protocol for machines is.

On top of that, there is no benefit, not one at all, to humans being able to
read it when tools already exist to interpret and display it even more human-
readable than its natural state. We squish and compress and strip HTML and JS
already just to make it more efficient, and then undo the whole process just
to read it. It's insane.

~~~
ricardobeat
So you really think we'd be here today if instead of HTML, CSS , Javascript,
JSON, XML we had a web based on bytecode formats?

The web is _made_ by people, not computers. Open an ubiquitous text-editor and
you can start working on something right away. If you have to download a dozen
different compilers and IDEs to do that, it's definitely not the same.

~~~
peterwwillis
"The web" is actually just a collection of hyperlinks, applications that parse
markup and document storage and retrieval services. You don't see code. You
see pictures of cats. And you never, ever need a text editor to use it.

Face it. Your love affair with ASCII is just that: an emotion.

(As to your original question: humans haven't needed to program in binary or
assembly for decades. That's what so great about computers: they do the hard
work for us, so we don't need to type everything manually into a text editor.
Is that such a hard pill to swallow?)

~~~
ricardobeat
You're completely ignoring the fact that the web began as (and still is, in
part) a collaborative tool and _publishing_ platform. Text-based formats
played an immense part in that, geocities, the rise of personal publishing,
blogs, these would not have happened without them.

Yes, binary is more efficient, but then tell me why is JSON the most popular
data interchange format on the web today?

~~~
peterwwillis
Because XML, the preeminent human-editable data interchange format, sucked
balls. It's only superseded YAML because it can be stripped of whitespace and
it has the word "Javascript" in it.

~~~
walterstucco
binary formats sucked so much, that they had to invent XML and it was a much
better way to start the interaction era, were services talk to each other
without having to read a 30 page spec just to understand how to write the
right payload for the interchange format used. Let alone the byte order...

------
joosters
At first glance, the spec appears to be re-implementing a TCP stack inside a
TCP connection...

~~~
wmf
Yes, the reason is that starting a new stream multiplexed inside an already-
open TCP connection is faster than starting a new TCP connection. Attempts to
improve TCP itself are slowed down by slow uptake of new Windows versions.

~~~
joosters
That's not true. HTTP/2.0 (or at least the successor to HTTP/1.1) has been
discussed for over a decade, there have been many OS releases since then!

Inventing a whole new protocol to overcome a TCP deficiency is IMO a terrible
motive...

~~~
pritambaral
These guys have something to say about that:
[http://blog.chromium.org/2013/06/experimenting-with-
quic.htm...](http://blog.chromium.org/2013/06/experimenting-with-quic.html)

A new protocol that runs on UDP precisely to side-step slow TCP changes.

~~~
nly
That's great, but it means it'll always be a userland library rather than a OS
supported networking protocol... which means the API will never be a defacto
standard akin to the BSD sockets API. The reference implementation is also in
obtuse looking C++... which will hinder bindings to other languages.

In short, don't expect to see this outside of Android or Chrome.

On the plus side, this is exactly what UDP was for in the first place.

------
antirez
Congrats to Google for ruining the internet standards in an official way,
without strong proofs of big significant improvements over the simpler past
protocol.

~~~
tptacek
Don't confuse the cart and the horse. The IETF standardization process has
never been less relevant than it is today. The reality of deployment of a
"next-generation HTTP" involves two things, neither of which the IETF has any
say in: (a) whether anyone can improve HTTP as it runs between a mainstream
browser (or some as-yet unforeseen browser replacement) and a content serving
backend in a way meaningful enough to drive adoption, and (b) buy-in from the
major browser owners.

That's the way it's supposed to work; the horse is meant to drag the cart. The
RFC database is littered with cart-led insurgencies that went nowhere. If
binary HTTP is one of those, it'll join them as a historical curiosity.

~~~
antirez
My fear is that now that Google controls a significant part of HTTP traffic,
plus the _client side_ of the story (Chrome + Android), it is in a condition
to force things in one way or the other...

~~~
reidrac
Do you think Google is now in a better position to force things in one way or
another than Microsoft was in the 90s?

~~~
hugi
It's in a similar position. And see how that ended up with Microsoft — we're
still suffering the consequences.

~~~
chc
I'm actually kind of OK with XMLHttpRequest.

~~~
amenod
I am quite sure Microsoft views it as huge mistake on their part. :)

------
lnanek2
Well this is clever:

" HTTP/2.0 enables a server to pre-emptively send (or "push") multiple
associated resources to a client in response to a single request. This feature
becomes particularly helpful when the server knows the client will need to
have those resources available in order to fully process the originally
requested resource. "

If someone asks for your HTML, might as well send them the CSS, JS, and images
it is going to use. Would cut down on requests. Only thing more efficient than
compression, is not having to ask in the first place.

~~~
duaneb
It also complicates caching: do you cache the response by request, or cache
the resources individually by update time (or whatever)?

------
stormbrew
I still feel like this is just being rammed through far far too fast. SPDY
might well be the right way to go, but it's only been deployed for a small
number of very large sites for a couple of years at this point. It was a
foregone conclusion when the schedule was announced for http2.0 that it would
be spdy, because only spdy has demonstrable value in production. There was no
time for anyone to come up with or evaluate an alternative. But on the other
hand, there hasn't been near enough time to demonstrate that spdy is good _for
the whole internet_ , which is what blessing it with the http protocol name
implies.

And I just don't see why it _should_ be rammed through. SPDY has a connection
upgrade path, that afaik is largely unchanged for http2.0 anyways.

~~~
drivebuy
> because only spdy has demonstrable value in production.

What demonstrable value? Google has _never_ compared it to pipelining and when
Microsoft did so they found it about the same and sometimes slower.

There is next to zero value in SPDY over pipelining across several
connections. It's just complicated for no good reason.

~~~
stormbrew
I think you're seeing a defence of spdy in my post that isn't really there. By
value I mean simply that it is at least functional. Any alternative proposal,
given the short proposal cycle, would not even have that.

------
abhshkdz
Source code & issues tracker:
[https://github.com/http2/http2-spec](https://github.com/http2/http2-spec)

Wiki: [http://tools.ietf.org/wg/httpbis/](http://tools.ietf.org/wg/httpbis/)

------
sktrdie
Can anybody summarize the main differences between this and the older versions
of HTTP?

~~~
xcnm3
Current version of HTTP was devised by engineers. The new version is devised
by an advertising company/NSA puppets.

~~~
frou_dh
If you're a proponent of engineering then why are all your comments on the
matter vague and/or emotional?

~~~
xcnm3
I feel it's necessary to remind other posters who we're dealing with. The
Google problem should not be ignored, every engineer in that company is now
suspect.

------
joeyh
"PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"

Ah, so every HTTP 2.0 connection has PRISM in it.

~~~
bbanyc
It started out as "FOO ... BAR" but that made the header an odd number of
bytes long. In the previous draft it was "FOO ... BA". It was briefly "STA ...
RT" which made too much sense to use.

------
Sephr
You still can't self-sign certificates and rely on certificate pinning for
transport security without domain verification. With all of the security
concerns people have with governments logging all unencrypted internet
traffic, I was hoping HTTP 2.0 would require or at least optionally allow
self-signed cert TLS for every http: connection (with no UI indication to the
user that they are secure) and require CA-signed cert TLS for https:

We're also still stuck with DEFLATE, which is vastly inferior to modern
compression formats like LZMA.

~~~
samwillis
Encryption is only half the problem, authentication is the other. Self signed
certificates don't authenticate the web server and allowing them would open
the web up to MITM attacks. What we need is some form or decentralised
certificate authority, i have no idea how that could work though.

HTTP allready supports LZMA, its just the browser and web servers that dont.
If a browser sent the header:

    
    
      Accept-Encoding: compress, gzip, lzma
    

instead of:

    
    
      Accept-Encoding: compress, gzip
    

and the server supported it, it would "just work". Unfortunately none of the
major browsers or server have implemented it.

~~~
skrause
_What we need is some form or decentralised certificate authority, i have no
idea how that could work though._

DNSSEC could be used to distribute certificates:
[https://en.wikipedia.org/wiki/DNS-
based_Authentication_of_Na...](https://en.wikipedia.org/wiki/DNS-
based_Authentication_of_Named_Entities)

~~~
jimktrains2
Isn't DNSSEC still have centralized certs for the tlds?

------
jlarocco
Going to binary seems kind of silly at this point.

HTML is text. Javascript is text. XML is text. JSON is text. SVG is text. CSS
is text.

Is it really worth the complication to save a few bytes on HTTP headers when
you're just going to shovel out inefficient text data in most cases anyway?

I don't understand why they're trying to shove this down everybody's throat as
a new version of HTTP.

There are a ton of ports besides 80. The better thing to do, IMO, would be to
make a new protocol on some other port and add it to their browsers.

~~~
josteink
According to the shills employed by or rooting for Google, here on HN and
elsewhere on the internet, it's not silly: It is _paramount_.

See, it allows the request for www.google.com, including all of Google's
tracking cookies, to fit inside one TCP-frame, causing a 5ms improvement in
load time, and Google has evidence that this means they make more money.

Never mind the open, exploratory nature of the internet and how text-based
protocols was what made the internet into what it is today. We're going to
throw away all that which the internet has taught us about that because Google
says we should.

This thing is fucked up beyond belief.

Edit: found a link to the IETF discussion about this:

[http://lists.w3.org/Archives/Public/ietf-http-
wg/2013JanMar/...](http://lists.w3.org/Archives/Public/ietf-http-
wg/2013JanMar/0254.html)

It admits in plain sight that the only thing they care about with HTTP 2.0 is
solving Google's massive-scale issues at the cost of everyone else:

> I finally admitted it was a dead end. At the moment the challenges consist
> in feeding requests as fast as possible over high latency connections and
> processing them as fast as possible on load balancers

A good, open, self-documenting protocol didn't suit Google, so let's throw it
away. It's a "dead end", after all.

Jesus christ these people need a bitch-slapping.

More emails on the subject can be found here:

[http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-...](http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=subject&hdr-1-query=The+use+of+binary+data+in+any+part+of+HTTP+2.0+is+not+good&index-
grp=Public_FULL&index-type=t&type-index=ietf-http-wg)

------
RyanZAG

      Only implementations of the final, published RFC can identify
      themselves as "HTTP/2.0".  Until such an RFC exists, implementations
      MUST NOT identify themselves using "HTTP/2.0".
    

Here we go again - as with -webkit in css, expect 'HTTP/2.0 DRAFT' or similar
to be the new http 2.0.

~~~
dragonwriter
I think in the real world its not "HTTP/2.0 DRAFT" but "SPDY".

------
antitrust
This makes it easier for web application designers, but is less optimal for
those publishing static pages, which are actually the mainstay of the web.

Further, it's less user-explorable, which further distances the web from
access by the everyday tinkerer as opposed to the professional with lots of
time to explore.

------
ddalex
Is this a proposal to reimplement (badly) TCP inside of HTTP ? So we'll have a
TCP stack running on top of a TCP stack ?

Those who don't learn history are doomed to repeat it.

I predict that this will lead to unexpected performance problems due to
collisions in Tx window size between TCP windows and HTTP 2.0 frames.

------
ge0rg
I really disliked the following part: _A client MAY immediately send HTTP /2.0
frames to a server that is known to support HTTP/2.0, after the connection
header. [..] Prior support for HTTP/2.0 is not a strong signal that a given
server will support HTTP/2.0 for future connections._ (Section 3.4)

That means, whenever you open a new TCP connection to a http2 server, you must
start with HTTP/1.1 and perform the Upgrade negotiation anew.

Making the spec require HTTP2 support on all servers of a cluster if at least
one server supports it would have been much better, performance-wise. The only
reason I see why they kept it is transparent proxies (if your browser is using
an explicit proxy, it should be able to figure out if the proxy supports
HTTP2).

~~~
peterwwillis
Browsers already send HTTP/1.1 by default, which would be rejected by HTTP/1.0
servers. HTTP/2.0 would be rejected by HTTP/1.1 servers and the browser could
retry, or it can try for the Upgrade.

Either way, with time, we can change the browser to behave differently based
on the number of servers supporting that protocol, the same as with HTTP/1.1.

~~~
ge0rg
Yes, but storing "supports HTTP2" for a given server for a given time after
connecting to that server and negotiating the upgrade would also do the job.

One of the problems with HTTP 1.x is that it is stateless - every time you
want something from a server, you treat it as if it is the first time you talk
to it. I understand this is by design, but as a consequence we are
transmitting all the same headers to the server all the time... which can be
mitigated with HTTP2, except that we still need to do that (send all headers)
_and_ the HTTP2 upgrade, every time we open a new TCP socket to that server.

------
ancarda
Hmm... I have a few scripts that do something like:

    
    
        header($_SERVER['SERVER_PROTOCOL'] . ' 400 Bad Request');
    

Since I'm using SERVER_PROTOCOL, if I upgraded Nginx and it started to send
HTTP/2.0 traffic to the server, would I need to rewrite this line? How would I
send a specific status code using the new binary protocol?

~~~
iso-8859-1
Just use

    
    
        header("Status: 400 Bad Request");

------
popee
HTTP/2.0 should be SIP because of similarities and also integrated session
management. Not some _application_ layer _binary_ protocol to spy on people
even faster. Yeah baby :-)

------
cientifico
Hope http 2.0 is the new ipv6 !

------
yalogin
Totally superficial but why do I have to type http every time? Why can't it be
h and hs (for https). Quicker to type.

------
neuroscr
Most of the complaints are around the ascii vs binary. Can we just make it
accept both and move on?

------
xcnm3
Given the close relationship between Google and the NSA, I suggest they are
removed from the IETF until further notice. I would trust Microsoft more than
the snake oil Google produces.

No surprise they've opted for a binary protocol rather than ASCII, anything to
reduce transparency

~~~
cromwellian
What close relationship between Google and the NSA are you referring to?

~~~
xcnm3
Google providing direct access to their servers and infrastructure. Every
Google service was open to the NSA; GMail, Google Drive, Google Talk, you name
it.

~~~
cromwellian
And the evidence for this is?

~~~
xcnm3
Please read the leaked information from Edward Snowden. I don't wish to
paraprase the last few weeks of news for someone.

~~~
cromwellian
It's a rhetorical question. None of the leaks provide any evidence that Google
actively cooperates with the NSA in any way. No evidence of equipment at
Google data centers, no evidence of any kind of remote access for the NSA,
other than the already existing legal channels.

The claim that Google had foreknowledge of PRISM, or worked with the NSA to
build some kind of firehose for them is unsupportable given what we know, and
is pure speculation on your part.

Thus, the claim of close cooperation with the NSA is frankly, ad hominem.

~~~
bitwize
Absence of evidence is not evidence of absence.

Given what's come out about the NSA, it's much more plausible to assume that
Google is cooperating with them.

