LWN: Comments on "What's new in HTTP 2"

What's new in HTTP 2

nye — Mon, 29 Jul 2013 12:55:41 +0000

>What is the defence against servers which do not respect the specification and keep on initiating streams upon receive of a GOAWAY frame?

This kind of question doesn't really make sense. How can the specification meaningfully specify the behaviour of things that are operating outside of the specification? When you're talking about a server which doesn't follow required standards and arbitrarily starts sending unrequested data, it makes no difference whether it's an HTTP 2 server with bugs, an HTTP 1.1 server with bugs, somebody trying to ssh into the wrong IP address, or just some random port scanner.

There is no difference between this problem and the more general problem of receiving unwanted TCP connections, and once you've realised that, the solution is obvious: RST, netfilter, filing a formal complaint, legal action, etc. (roughly in order, though in practice of course it's vanishingly uncommon to get past step 2)

What's new in HTTP 2

mathstuf — Sat, 27 Jul 2013 18:19:01 +0000

If they're not following HTTP2, why should you? Send a reset packet and let the user know the server is misbehaving, or collaborate a DoS, or drop the hostname into /etc/hosts as a black hole. The possibilities really are endless :) .

What's new in HTTP 2

hasard — Sat, 27 Jul 2013 01:51:26 +0000

What is the defence against servers which do not respect the specification and keep on initiating streams upon receive of a GOAWAY frame?

What's new in HTTP 2

Karellen — Mon, 15 Jul 2013 16:40:34 +0000

Looking at it, I don't see why a client couldn't initiate the connection, send a GOAWAY frame with last-stream-id set to 0 (the stream-identifier for GOAWAY frames is also 0), and then send the HEADERS frame to initiate the first request.

According to section 6.8, the receiver or a GOAWAY frame is not allowed to initiate any new streams (6.8 para 1), but I don't see anything that says the *sender* is not allowed to initiate streams after it has sent a GOAWAY.

Did I miss that?

What's new in HTTP 2

raven667 — Sat, 13 Jul 2013 03:36:03 +0000

Single stream to a single IP, but often web pages pull resources from a half-dozen or more IPs, if the 10-frame initial-window takes off that could still be nearly 100 full sized frames coming your way without any means to signal for congestion or provide back pressure.

What's new in HTTP 2

DavidS — Fri, 12 Jul 2013 21:52:09 +0000

Since this goes all over a single TCP stream, I'd expect HTTP to avoid some of the thundering herd problems that Gettys was talking about, when he was 'complaining' about the large initial windows of today's TCP.

What's new in HTTP 2

n8willis — Fri, 12 Jul 2013 19:20:11 +0000

Well, I don't believe so. The PUSH_PROMISE frame's contents are a stream ID. You can't send a RST to kill a stream before you know what the ID is of the stream you want to kill. Unless you send resets for every possible server-initiated stream ID ... in which case you'd be the one taking up excess bandwidth.

But in any case, the client initiates all HTTP connections with a request; I don't believe a server would set up a new connection if it got a RST frame or a GOAWAY frame from a client with which it has no open connection.

Nate

What's new in HTTP 2

Karellen — Fri, 12 Jul 2013 11:30:30 +0000

AFAICT, a client could send the server push opt-out as the very first frame, before requesting any resources at all. It seems unlikely that a server would push anything before knowing whether the client is even going to ask for an valid resource, or, e.g. /robots.txt

What's new in HTTP 2

Aissen — Fri, 12 Jul 2013 10:43:47 +0000

I would have liked to see the differences between SPDY and HTTP 2.0. How much do they differ ?

What's new in HTTP 2

kjp — Thu, 11 Jul 2013 14:36:58 +0000

great writeup. but seriously, server push is opt out (after you've already been spammed with some data) instead of opt in by clients? That just seems insane.

It just looks like a bunch of boring micro-optimizations to me, though.

What's new in HTTP 2

smitty_one_each — Thu, 11 Jul 2013 12:27:19 +0000

Concur. Again showing why LWN is completely worth the subscription.

What's new in HTTP 2

dune73 — Thu, 11 Jul 2013 11:37:52 +0000

Thank you for this interesting summary, Nathan.

What's new in HTTP 2

davecb — Thu, 11 Jul 2013 11:26:03 +0000

Interestingly enough, Jim Gettys just posted an essay on latency that discusses "Web Performance and It’s DOS attack on the Internet".

It will be interesting to see if HTTP 2 addresses these concerns about DOSing oneself or is a move in a different direction.

--dave