W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: HPACK

From: Michael Sweet <msweet@apple.com>
Date: Wed, 18 Jun 2014 08:10:24 -0400
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <C21B5CE7-9152-4636-AD22-424C08F3CE57@apple.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cory,

On Jun 18, 2014, at 6:20 AM, Cory Benfield <cory@lukasa.co.uk> wrote:
> On 18 June 2014 10:52, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>> and I would mandata that a request always provide the following
>> fields in this exact order, as the first fields in HEADER(...):
>> 
>>        :scheme
>>        :method
>>        :authority
>>        :path
>>        :query
>> 
>> and that responses always have the :status as the first field.
>> 
>> My finger in the air estimate that this reduces the processing
>> requirement for the "is this a trivial case" decision by about
>> a factor of ten.
> 
> This is an interesting proposal, I'll be interested to see the
> response it gets from the list. This isn't problematic for hyper to
> do, though having to sort the headers is a bit of a pain. I wonder if
> it defeats the 'streaming' nature of HPACK, however, if we mandate
> some kind of ordering from the higher layers.

Given that these fields are what forms the initial request line in HTTP/1.1, I don't think it will be an issue for streaming...

I'm also +1 on this, and FWIW IPP mandates something similar in its message encoding.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


Received on Wednesday, 18 June 2014 12:10:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC