- From: Mark Nottingham <mnot@mnot.net>
- Date: 2013年9月14日 09:54:25 +1000
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-Id: <7FC7097F-F635-4985-B1B3-91EBBA7E9B7E@mnot.net>
I've considered using them for a few things over the years. However, two things always stopped me; they aren't accommodated by Apis, and they aren't guaranteed to transit a hop. For the breach attacks, I don't think deprecating them harms things, since you can still sen them; in these mitigations, the payload / semantics don't matter, as long as something is there. Personally, I'm ok either way; the important thing is to document their behavior / limitations. Deprecation I one way to do that, but we could do it in prose too. From a chair perspective - we need to wrap this up. If we can get clean consensus to change quickly, great. Otherwise, lets leave it be. Sent from my iPhone On 14/09/2013, at 8:01 AM, "Roy T. Fielding" <fielding@gbiv.com> wrote: > 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 23:54:55 UTC