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

Re: #445: Transfer-codings

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Fri, 4 Apr 2014 15:52:24 +1000
Message-ID: <CACweHNCzs-6WYfHV3SpDw8-DS36i+N8ukh84yoYdp7PWzUcOYw@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 4 April 2014 15:09, Mark Nottingham <mnot@mnot.net> wrote:

> My personal .02 -
> Given that HTTP/1 hasn't seen much use of transfer-codings, and over the
> years we've had them, there have only been three defined (discounting
> chunked), spending 16 bits on this in ever data frame doesn't seem
> justified.

To be honest, the size is a completely negotiable detail. I went with 16
because the SETTINGS frame has a 32-bit Value. Old-school q-values have
1000 effective values, which needs at least 10 bits to encode; and 16 bits
is a convenient word size >=10. That leaves 16 bits in the Value, so rather
than mandate a bunch of "must be 0, fail if they're not" bits, I just used
all 16 for the identifier.

If that results in too much overhead in the DATA frames, I have no qualms
at all about changing the size, and the packing in SETTINGS. Though surely
the compression would already compensate for the extra two bytes; otherwise
why bother encoding in the first place?

I'd much rather just have a flag that indicates 'gzip', and a corresponding
> setting; that doesn't require any frame format changes at all. If another
> encoding becomes necessary, it can get into a subsequent version (since
> we've repeatedly decided to favour faster versioning over broad
> extensibility in the non-semantic layer).

My only issue with this is experimentation. I wouldn't want to have to
push out a whole new HTTP version just to support, say, bzip2 or LZX or xz
compression. Rather, we could allocate a range of encoding values as
"private use" or "experimental", say 32,768 to 65,535, and I could
configure my endpoints to treat 32,999 as xz, without having to change any
deeper handling of flags or frame formats or anything.

Also, how should a recipient handle a stream that has DATA frames with
> different values for encoding?

By decoding each as it arrives, the same way it would handle a stream with
the same encoding every frame. Two gzip'd frames don't add together to
make one big gzip file.

  Matthew Kerwin
Received on Friday, 4 April 2014 05:52:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:11 UTC