W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Next Steps for HTTP/2.0

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 5 Feb 2013 16:34:00 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <7A36AAB9-5B0D-40C0-82EA-02FC8F5A0E0E@mnot.net>
To: James M Snell <jasnell@gmail.com>

On 05/02/2013, at 4:19 PM, James M Snell <jasnell@gmail.com> wrote:

> 
> 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).

That was the sense I had.


> 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.

That was very much the sense at the F2F, and was the motivation behind avoiding binary encoding for now. 

A fair number of people share your concerns about the cost of state management; I anticipate that much of the discussion going forward is going to be about containing and controlling it.


>  [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.

Seems reasonable, if we don't block on it.

Cheers,

--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 5 February 2013 05:34:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2013 05:34:19 GMT