Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

Comments/Questions on 
http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2
"Hypertext Transfer Protocol version 2 draft-ietf-httpbis-http2-16"

Overall, for someone with good understanding of HTTP/1.x, this specification is good to read and well structured. The stream states ascii art is informative, though it on first glance implies PP to be on the wrong stream id. Maybe the legend could give a hint that PP works different from all other frames.

I have no comments regarding the language (not a native speaker), not did I check the dots and crosses. I tried to read it with my background in implementing HTTP as someone wanting to code it. Therefore most questions/issues below are concerned with things where the spec could be a bit more specific. According to my taste, that is. Things can be overspecified as well...

With that said, and with respect to all the work done, my comments/questions:

1. "hop-by-hop" vs. "end-to-end" references
At two locations in the spec (5.2.1 Flow Control, 6.9 WINDOW_UPDATE) the distinction between "end-to-end" vs. "hop-by-hop" is being made without explaining how h2/h2c would work with an intermediate. Maybe that is left undefined intentionally. But if a HTTP2 intermediate is a forward or reverse (CDN) proxy, I think it must always
- renumber stream identifiers
- uncompress HEADERs from the upstream and recompress for downstream
- consider carefully the mapping of stream and connection errors
So in what way is it meaningful to see HTTP2, the thing carrying HTTP requests/responses, as more than hop-by-hop?

2. PUSH_PROMISE and header completeness
How are cache sensitive headers like "Authorization" handled in PUSH_PROMISE request headers? If simply left out, the client could store pushed resources in a cache where they do not belong. Should servers use extra Cache-Control directives in such pushed responses?

Related: how is the role of the ACCEPT-* request headers? Should a client reject PUSH_PROMISE with request headers that does not match its own ACCEPT-* preferences? What if it uses ACCEPT-* and the PUSH_PROMISE is lacking those? Or the other way around?

3. Clarification on server-initiated push?
In discussions with colleagues some had the notion that HTTP2 would allow server initiated "requests". My reading of the draft is that this is not really the case. Server pushes are only defined for streams opened by the client.
- Is this the correct reading of the spec?
- If yes, has HTTP2 any advise how to best do long polling or what is the recommended alternative?

4. SETTINGS_MAX_HEADER_LIST_SIZE as advisory
It seems undefined what a client (library) should do with it. Will this not give rise to interop problems if one client respects it and fails requests immediately while another does no checks and sends them anyway? MUST a peer that announces a limit always reply with 431 to requests that exceed it? 

5. Graceful connection shutdown
GOAWAY seems to serve two purposes:
- inform peer of highest process stream before closing, so that retries can be done safely
- initiate a graceful connection shutdown
What is expected of a client upon receiving a GOAWAY with Last-Stream-Id 2^31-1, e.g. graceful shutdown?
- it must no longer create new streams
- it should expect a future GOAWAY with a lower stream id
- it can expect responses on half-closed streams?
- it should RST all incoming PUSH_PROMISEs?
(And of course, a connection can always simply break at any time...)

6. Optimisation: Default SETTINGS values same for clients and servers?
I would think that clients have different preferences for defaults than servers. Especially for INITIAL_WINDOW_SIZE. Since differences to defaults need to be send for every HTTP2 connections, are the current values good?
Related: if a peer sends/receives an empty SETTINGS at connection start, do acknowledgements serve any purpose?

7. Opinion: Chapter 9.1 Limitation to single connection
Have we not been here before? In the past, such SHOULD NOTs have not been very helpful. (Most likely already discussed heavily on the list...no strong feelings about this. It will be ignored anyway if not proving useful.)

Best Regards,

 Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Received on Tuesday, 6 January 2015 13:14:01 UTC