
RFC 7540 – HTTP2 - treve
http://www.rfc-editor.org/rfc/rfc7540.txt
======
thisrod
A lot of this sounds like transport layer instead of application layer. I'm
curious why it ended up in HTTP instead of TCP.

For example, you could specify that ports 49152 to 50179 formed a block on a
given host, and so on in groups of 1028. Ports in a block would have to
connect to the same port on the other end, and would share a packet buffer.
There could be some rules to let the network stack pass on data to a process
in anticipation of a three way handshake completing, TLS could assume that new
connections shared the same secrets as existing ones, and so on. That seems
simpler, and it prevents the wheel from having to be reinvented for every new
application protocol.

An obvious reason not to do that is that TCP is too widely used for the
effects of changes to be predicted. Is that the only reason?

~~~
jballanc
It's funny to think that a mere 20 or so years ago, ethernet wasn't even a
foregone conclusion. The first time I connected a computer to a network, I had
to make sure I was plugging into the ethernet and not the token ring. Now here
we are pushing transport layer fixes into the application layer just because
we don't want to have to explain to sysadmins how to reconfigure their
firewalls?

~~~
digi_owl
I think it is aimed more at home users that are stuck behind a NAT the ISP
controls than sysadmins.

~~~
rkangel
So we're not fixing the transport layer due to limitations in the network
layer that _have_ been fixed, we're just not using them.

~~~
dtech
You mean IPv6? That suffers from exactly the same problem: ISP's just don't
give a damn and don't roll it out.

You cannot expect your average internet user to know about these things, so
they get away with it.

~~~
nly
Major residential ISPs aren't rolling out IPv6 largely because they already
have enough IPv4 space for their customers.

Take a major UK ISP like Virgin Media. According to Hurricane Electrics BGP
looking glass project they are originating 9.4M IPv4 addresses[0], however, at
the end of 2012, according to Wikipedia[1], they only had 4.8M customers.

[0] [http://bgp.he.net/AS5089#_asinfo](http://bgp.he.net/AS5089#_asinfo) [1]
[https://en.wikipedia.org/wiki/Virgin_Media](https://en.wikipedia.org/wiki/Virgin_Media)

~~~
georgerobinson
Virgin Media can't even expand that easily because they must lay cable in
areas that weren't covered by NTL/Telewest infrastructure: and I believe is
extremely expensive and time consuming with planning permission being what it
is.

------
bsimpson
I'm surprised to see that even Safari and IE implement SPDY:

[http://caniuse.com/#feat=spdy](http://caniuse.com/#feat=spdy)

If you're working on a new app and your primary concern is modern browsers, if
your network stack supports it, you could probably design for HTTP/2 from the
get-go. That's exciting - no more choosing between semantic code and boosting
performance with hacks like image spriting.

------
pornel
It's annoying that IETF so behind the times that they still don't use HTML for
their RFCs. In the last 20 years they've published 3 specs for hypertext
transform protocol, but are still unsure about actually using hypertext yet.

They're probably very concerned about readability on a VT-100 by users who
don't have enough memory to run Lynx.

In the meantime the spec is unreadable on a mobile phone screen (their "HTML"
version of the RFC is still the same fixed-width text stuffed in a `<pre>`
tag).

~~~
treve
There's probably a XML version, which mean you can use the standard XSLT sheet
to get HTML output that's not confined to 75 characters on a line.

But completely agree... they still haven't agreed on UTF-8 either, and still
require ASCII.

------
jMyles
Lukasa gave a great talk at PyCon on HTTP2:

[https://www.youtube.com/watch?v=ACXVyvm5eTc](https://www.youtube.com/watch?v=ACXVyvm5eTc)

It is my hope that hendrix[0] will have HTTP2 support before DjangoCon in
September.

0:
[https://github.com/hangarunderground/hendrix](https://github.com/hangarunderground/hendrix)

------
malnourish
While I took and thoroughly enjoyed my networking course back in school, I am
still left wondering:

What features will an end-user now be able to enjoy because of this new RFC?

~~~
josteink
You have a completely warped perspective here.

This is something Google pushed, so that Google can have as many tracking
cookies as they like when you browse the internet, without the cookies causing
a noticeable performance degradation because a http request might exceed the
American DSLs MTU size.

This was one of the primary engineering criterias. No really.

There's no features in it for the _user_.

~~~
WireWrap
I've only begun to study the protocol, but some things in the privacy section
do concern me. Particularly:

HTTP/2's preference for using a single TCP connection allows correlation of a
user's activity on a site. Reusing connections for different origins allows
tracking across those origins.

Imagine a home or business where devices are configured for some privacy
(cookies and various other things generally blocked) and the machines are
communicating through a NAT or Gateway/Proxy. Wouldn't reused connections
represent a unique threat in terms of allowing (third-party) websites to
discern the behavior of individual machines and users?

~~~
pcthrowaway
Perhaps my understanding is way off, but I don't think it's possible to reuse
a connection across different origins (unless perhaps the IP address of the
server was the same for those origins)

~~~
WireWrap
Well, this:

 _Clients SHOULD NOT open more than one HTTP /2 connection to a given host and
port pair, where the host is derived from a URI, a selected alternative
service [ALT-SVC], or a configured proxy._

suggests to me that if you have TopLevelOrigin1 open and TopLevelOrigin2 open,
and they both embed content from ThirdPartyOriginA, you'd (likely) have only
ONE connection to ThirdPartyOriginA. I thought that would be an example of
"reusing connections for different origins", and there would seem to be a
correlation risk.

I was thinking that the "one connection per host:port" would (normally) be
based on host NAME. However, your comment and the fourth paragraph in 9.1
Connection Management leaves me thinking that it could (optionally) be based
on resolved IP Address.

To further complicate things, Alt-Svc can redirect requests to a different
host. So HTTPS requests to TopLevelOrigin1 and TopLevelOrigin2 could all go to
example.com and its IP Address.

Maybe a (welcomed!) reply will help clarify the correlation risk scenarios.
I'll also search for prior discussions about it.

~~~
cesarb
That doesn't increase the correlation risk, since the same could be done today
with TLS session IDs or session tickets: even if you open more than one
connection to the third party, your browser will attempt to reuse the same TLS
session for performance reasons (it shortens the handshake and avoids
expensive public key calculations).

On the flip side, the use of TLS means that connections to different origins
must be kept separate, even with Alt-Svc. If I'm reading
[https://tools.ietf.org/html/draft-ietf-httpbis-alt-
svc-06](https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-06) correctly,
"example.com" MUST present the certificate for TopLevelOrigin1 or
TopLevelOrigin2, which obviously requires a separate TLS handshake and thus a
separate TLS session for each one.

~~~
WireWrap
I appreciate you mentioning the Session ID and Session Ticket scenarios. Those
can be disabled though, correct? HTTP/2 over cleartext TCP is also possible?
Maybe still some increase in correlation risk due to those?

Do you think the Alt-Svc scenario we are talking about would guarantee two
separate HTTP/2 connections?

~~~
cesarb
> I appreciate you mentioning the Session ID and Session Ticket scenarios.
> Those can be disabled though, correct?

Yes, the server can ignore both and always start a new session. And you could
modify a client to never send either, but if you are already modifying the
client code you could also modify it to always use a separate connection.

> HTTP/2 over cleartext TCP is also possible?

In theory yes, in practice most will only implement it over TLS, to avoid
middleboxes breaking it. TLS-intercepting middleboxes won't negotiate HTTP/2,
so it'll fallback cleanly in that case.

> Do you think the Alt-Svc scenario we are talking about would guarantee two
> separate HTTP/2 connections?

Alt-Svc to a different hostname will always use TLS. From the draft: "Clients
MUST NOT use alternative services with a host that is different than the
origin's without strong server authentication; this mitigates the attack
described in Section 9.2. One way to achieve this is for the alternative to
use TLS with a certificate that is valid for that origin."

And with current TLS, the hostname is sent on the handshake (SNI), so it can't
use the same session for different hostnames.

~~~
WireWrap
I think the security.ssl.disable_session_identifiers pref in Gecko browsers is
meant to allow for it without modifying the code, and I haven't spotted a
similarly easy way of controlling HTTP/2 connections. Otherwise, point taken.

Is there anything we haven't discussed that would fall within the HTTP/2
spec's "Reusing connections for different origins allows tracking across those
origins." warning?

------
xrstf
See also
[http://www.ietf.org/blog/2015/02/http2-approved/](http://www.ietf.org/blog/2015/02/http2-approved/)

~~~
turingbook
Why is it approved in Feb. but published in May?

------
collinmanderson
ENHANCE_YOUR_CALM made it into the official spec. :)

------
istvan__
Binary protocols ftw!

------
SimeVidas
Apple needs to deliver at WWDC next monyh

