- From: Roberto Peon <grmocg@gmail.com>
- Date: Wed, 30 Apr 2014 04:07:52 -0700
- To: Matthew Kerwin <matthew@kerwin.net.au>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNdzUubw5C-CZALt5QovLntcHxLC2swAesEg8A4C+rbQ5A@mail.gmail.com>
On Wed, Apr 30, 2014 at 3:55 AM, Matthew Kerwin <matthew@kerwin.net.au>wrote: > [snipping] > > On Apr 30, 2014 4:44 PM, "Roberto Peon" <grmocg@gmail.com> wrote: > > > >> But even so, why do you have to fix it in HTTP/2? And why does it hurt > h2 to *not* fix it? > > > > Compression is an important part of making latency decrease/performance > increase, and, frankly, there is little practical motivation to deploy > HTTP/2 if it doesn't succeed in reducing latency/increase performance. > > Do the other improvements in HTTP/2 not give those successes? Or are you > saying that they're not enough without ubiquitous payload compression? > Each helps for specific usecases. And I am saying that ubiquitous compression of the payload is a big deal for many of the browsing cases where the resources are larger, as is very often the case with HTML/css/js and other resources. > >> > The proxy, when forwarding the server's response to the HTTP/1 > client, must ensure that the data is uncompressed when forwarding to the > HTTP/1 client since the client didn't ask for c-e gzip. > >> > >> Cache-Control:no-transform explicitly forbids the proxy from altering > the representation. It's not allowed to decompress it. > > > > In fact what we're doing is offering two representations simultaneously. > > > > It's a very messy way of doing it, though, and it makes me nervous. Too > many edge cases, too many potential holes. That's ok for a de facto > standard or something, but not for a formal IETF spec. And it strikes me as > a big disincentive to adoption. > > To get it right would hold back HTTP/2 (unneccessarily, I say), so don't > rush it in there. Hold off for the next iteration. I'd be happy if HTTP/3 > focused solely on fixing compression. I suspect others would be too. > Arguably the t-e stuff is more complicated, so I guess I disagree there. I'm certainly up for other fixes in HTTP/3, but I don't feel that the feature which is already implemented is something we should throw out now when the fix is relatively easy. -=R
Received on Wednesday, 30 April 2014 11:08:21 UTC