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

Re: #445: Transfer-codings

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 11 Apr 2014 18:26:33 +1200
Message-ID: <53478B19.8020902@treenet.co.nz>
To: ietf-http-wg@w3.org
On 11/04/2014 3:58 a.m., K.Morgan wrote:
> On Thursday,10 April 2014 08:17, Matthew Kerwin wrote:
>> I wanted to keep the rank because I'd like the ability for someone to change their mind about an encoding.
>> I would be happy with a single bit, if I could come up with a way to pack it into the settings frame that doesn't make me feel yucky. ...
> 
> I'm neutral on whether you use a single value for this setting or keep a table like Amos wants. ( I always slightly lean towards KISS though.)  I just didn't realize there was a desire to dynamically switch between so many options.
> 

Note: KISS for a proxy is the table...

A proxy which is contacting more than one server (ie the common case).
 Each server connection may negotiate or require a separate TE
compression be used.
Translating independent server and client encodings is complex and
requires extra state. Whereas negotiating a set/table of TE with the
client allows server TE to negotiate items from that table. Thus the
proxy can then pass-through the encoded frames from multipe different
servers TE without extra compression state or logic.


> Another idea for the setting...
> 
> 7-bit encoding with 1-bit on/off (128 possible encodings) - you could still pack four encodings into a single setting value
> ```
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |F| Encoding(7) |F| Encoding(7) |F| Encoding(7) |F| Encoding(7) |
>   +-------------------------------+-------------------------------+
> ```
> 
> The msb in the encoding field ("T") of the DATA frame could be used to signal the presence of an optional (encoding-specific) trailer that signals the offset and length of the uncompressed data captured within the compressed frame.
> This might allow intermediaries to quickly index the underlying uncompressed data.
> I don't care strongly about this idea, only if the intermediaries think it would be useful. I'd rather keep it simple.
> 

Trailers are nasty. While this may sound okay to begin with, as others
have said with the LZ compression methods under discussion in most of
these threads proxies can concatenate DATA of a stream without
decompressing. It also reduces the frame payload size usable for
compressed data (which could be significant amount of decompressed content).


> e.g.
> 
> ```
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  | Pad High? (8) |  Pad Low? (8) |T| Encoding?(8)|
>  +-------------------------------+-------------------------------+
>  |                            Data (*)                         ...
>  +---------------------------------------------------------------+
>  |                  Uncompressed Offset High? (32)               |
>  +---------------------------------------------------------------+
>  |                  Uncompressed Offset Low? (32)                |
>  +---------------------------------------------------------------+
>  |                    Uncompressed Length? (32)                  |
>  +---------------------------------------------------------------+
>  |                           Padding (*)                       ...
>  +---------------------------------------------------------------+
>  |                           Padding (*)                       ...
>  +---------------------------------------------------------------+
> ```
> 

Amos
Received on Friday, 11 April 2014 06:27:37 UTC

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