- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Thu, 3 Sep 2015 10:48:49 +0200
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>
- Cc: ietf-http-wg@w3.org, The IESG <iesg@ietf.org>, Mark Nottingham <mnot@pobox.com>
On 2015-09-03 03:01, Stephen Farrell wrote: > > > On 03/09/15 01:52, Mark Nottingham wrote: >> Something like this, perhaps? >> http://httpwg.github.io/specs/rfc7540.html#rfc.section.10.6 > > Yes and no. > > No. The URL above is for HTTP/2 and this is a header usable in > HTTP/1.1 so is not the same. Adding this to a system that is > currently safe wrt BREACH is also perhaps not the same as doing > HTTP/2 from scratch and ending up safe wrt BREACH. Note that the spec doesn't really introduce compression for client->server. This feature has been around for ages. All the spec does is make feature discovery and diagnostics easier. I agree that it would be good to have security considerations with respect to gzip encoding in HTTP/1.1, but that ultimately belongs into the revisions of RFC 7230 and 7231, not here. (I just opened https://github.com/httpwg/http11bis/issues/6>). > But more importantly, yes, I'm asking about the kind of analysis > that lead to the section 10.6 you point at. There was no analysis because the use of compression in this client->server direction really really isn't new at all. Best regards, Julian
Received on Thursday, 3 September 2015 08:49:13 UTC