HTTP/2 Draft 17

[Scottmitch]

New drafts are out. We should evaluate and make necessary updates.

https://tools.ietf.org/html/draft-ietf-httpbis-http2-17
https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-11
https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-12

We should coordinate with https://github.com/twitter/hpack if necessary.

[Scottmitch]

@nmittler @jpinner FYI.

[Scottmitch]

HPACK-11 didn't last very long :) We now have draft 12.

Note that the issue description and links have been updated.

[nmittler]

@Scottmitch ha! ... thanks for keeping on top of this!

[jpinner]

Will release hpack-1.0.0 once the spec gets published as an RFC. There will likely be minor API breaking since "Header Table" has been renamed in the spec to "Dynamic Table" (i.e. maxHeaderTableSize -> maxDynamicTableSize).

[Scottmitch]

@jpinner - That shouldn't be a problem. Thanks for the heads up.

I have seen a lot of chatter on the email thread about fixing static tables...do you think there is a draft 13 on the horizon?

[Scottmitch]

I am reviewing the draft 17 specification. There are a few changes to the spec which appear to be made for clerical purposes but may have unintended implications. I have opened issues on the http2-spec to get more clarity.
httpwg/http2-spec#726 - No change. Spec clarified to indicate perspective of the stream states being called out.
httpwg/http2-spec#727 - No change. Spec clarified to expand stream states which SETTINGS can impact for window update.
httpwg/http2-spec#730 - No change. Redundancy in spec removed in draft 17, but there was still text from previous drafts which keeps 0 padding restriction.

[nmittler]

@Scottmitch great work ... thanks for doing this!

[Scottmitch]

@nmittler - What are your thoughts on the following addition in section 8.2:

The server MUST include a value in the ":authority" header field for
which the server is authoritative (see Section 10.1). A client MUST
treat a PUSH_PROMISE for which the server is not authoritative as a
stream error (Section 5.4.2) of type PROTOCOL_ERROR.

Should we be providing an additional interface used to verify "authority" that the user must provide? Or should we follow the approach we used with the "cacheability" which is just to add comments? Verifying authority can be relatively involved and context dependent, but we could have a simple interface which forces the issue (which we decided against doing for the "cacheability" case).

[nmittler]

+1 for a simple interface. Something like:

interface AuthorityVerifier {
    void verifyAuthority(String authority) throws Http2Exception;
}

And they provide a default that always allows the authority.

I suppose we could do something similar for cacheability, but let's leave it as-is for now.

WDYT?

[Scottmitch]

@nmittler - Yes I like making it explicit...comments are too easy to miss.

[Scottmitch]

Draft changes have been cherry-picked. I'm going to open a separate issue for updating HPACK.

[Scottmitch]

See #3535 for HPACK updates.