Next Steps for HTTP/2.0

At the interim meeting, we developed a plan to get the HTTP/2.0 work moving. The goal is to get a draft marked for implementation soon, so that we can gather some implementation and deployment experience. Several folks at the meeting indicated that they would be implementing.

The plan we came up with is in the draft minutes, but I've separated it out below to kick off discussion, and to make sure we're all on the same page.

We identified the items below as goals for inclusion in that first implementation draft (expressed as a delta from the current WG draft):

* Upgrade
  - For now, we'll use NPN (until TLSWG gives us something to replace it with) for TLS connections.
  - For non-TLS connections, we'll use the "upgrade dance" as outlined in Gabriel's draft.
  - The DNS and Alternate-Protocol approaches are still under discussion, but won't be in this revision.

* Header Compression
  - We'll converge on a delta-based approach first; both Roberto and Herve have action items to publish drafts and show example code. The expectation is that we'll start with a fairly basic delta approach, and then tweak/evolve it over time.
  - Binary encoding of headers based upon their understood syntax is still under consideration, but won't be in this revision. We want to get experience with delta before adding complexity.

* Flow Control
 - Will is on the hook to produce a detailed proposal for session-level flow control, in addition to stream-based flow control.

* Settings
 - We'll mark settings persistence between sessions as "at risk", as it was felt that the added complexity and risk may not be worth the gains.
 - We'll document that it's mandatory to send the settings frame first upon connection establishment.

* Frame Changes
 - We'll remove the protocol version from the individual frame, but
 - We'll add magic at the beginning of session establishment (exact sequence TBD) to identify the protocol in use, and fast fail HTTP/1.x.
  - We'll rearrange frames so that they have uniform length and alignment as follows:
     - length: 16
     - type or opcode: 8
     - flags: 8
     - control: 1
     - session id: 31
  - priority will be changed to 32 bits (1st reserved).
  - Roberto is on the hook for a proposal for a "push promise" control frame as discussed.

Note that we are NOT yet firmly choosing any particular path; rather, we're working on proposals in code as well as text, based upon discussion to date. As such, we're likely to have several such implementation drafts that progressively refine the approach we're taking. I.e., we don't have to agree that the above is what we want HTTP/2.0 to look like -- only that it's interesting to make these changes now, so that we can test them.

The expectation that we set in Tokyo was that we'd have this nailed down in a draft sometime around the Orlando meeting, so that implementations could be finished soon thereafter, allowing us to start working on initial interop and data gathering. We'd then re-convene (possibly for another Interim) to discuss those results and discuss further work.

Please have a look through; if there's something else you think needs to be in this *first* implementation draft, please speak up.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 5 February 2013 04:20:49 UTC