Re: Next Steps for HTTP/2.0

On Mon, Feb 4, 2013 at 8:20 PM, Mark Nottingham <mnot@mnot.net> wrote:

> [snip]
> * 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.
>
>
One thing that I think we need to decide upon now is... is the header
compression mechanism going to be mandatory as THE way of encoding headers
in a session, or will the compression mechanism be optional. (Please say
that we're only going to have a single way of encoding headers).

We also need to lay out some fundamental goals for this. For example, I
think there's near universal agreement that tuning for maximum compression
ratios is not necessary the most important goal.. especially if it comes at
the cost of complicated and potentially expensive state management and
processing costs.

[snip]

> * 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.
>
>
I think it would be good to have the host header /
combined-method-host-port-path discussion down for this first
implementation draft. If we can nail down the approach to dealing with the
most critical headers, it ought to make it easier for us to collect data
and tune things later on in the header encoding and compression tasks.

- James


> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>