Re: #445: Transfer-codings

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
  http://matthew.kerwin.net.au/