- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Thu, 3 Sep 2015 10:47:23 +0100
- To: Julian Reschke <julian.reschke@greenbytes.de>, Mark Nottingham <mnot@mnot.net>
- Cc: ietf-http-wg@w3.org, The IESG <iesg@ietf.org>, Mark Nottingham <mnot@pobox.com>
Hi Julian, On 03/09/15 09:48, Julian Reschke wrote: > 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 don't understand your last sentence above. Isn't this a signal that will cause request compression to be turned on in cases when it wasn't previously? If not, then I at least misread the text. If so, then the "All" in your sentence doesn't seem correct. > > 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>). Ok good. > >> 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. Hmmm. S. > > Best regards, Julian > > > >
Received on Thursday, 3 September 2015 09:47:55 UTC