Re: chunk-extensions

On Oct 21, 2010, at 7:29 PM, Mark Nottingham wrote:

> What do people think about deprecating the use of chunk-extensions -- i.e., requiring that they be consumed, but not produced?
> 
>     chunk          = chunk-size *WSP [ chunk-ext ] CRLF
>                      chunk-data CRLF
>     chunk-size     = 1*HEXDIG
>     last-chunk     = 1*("0") *WSP [ chunk-ext ] CRLF
> 
>     chunk-ext      = *( ";" *WSP chunk-ext-name
>                         [ "=" chunk-ext-val ] *WSP )
>     chunk-ext-name = token
>     chunk-ext-val  = token / quoted-str-nf
> 
> I haven't seen any practical uses for them, and haven't seen any implementations that do anything with them other than throw them away. 

http://trac.tools.ietf.org/wg/httpbis/trac/ticket/343

I know this was closed a long time ago, but I have never been
comfortable with the idea of deprecating chunk-ext.  They were
originally intended to allow per-chunk signatures or hashes,
similar to those used in the Wave protocol.  More recently, they
have been considered as a potential solution to BREACH-style
attacks, specifically when a compression transfer encoding is
used within a TLS-secured connection. [There are other solutions,
of course, like changing the compression algorithms or changing
TLS, but chunk-ext is easier to deploy on a per-hop basis.] 

I am concerned that we might be deprecating something that will
be needed if we get widespread deployment of transfer-encoding
compression (instead of content-encoding compression).  Moreover,
recipients don't actually gain anything from this deprecation,
since they have to continue parsing for chunk-ext to remain
compatible.

Does anyone else share that concern?  It would be different if
we knew of systems that actually break on receipt of chunk-ext,
but I am not aware of any.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <https://www.adobe.com/>

Received on Friday, 13 September 2013 22:01:45 UTC