W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Negotiating compression

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 28 May 2014 12:28:39 -0700
Message-ID: <CAP+FsNeXHMd5d-apNhbfZ311wJmL0oFPZ7+OqHVR1KZnKMf+2Q@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I can't answer why for everyone, but yes, for this part at least, the
motivation was to be able to deploy an HTTP2 proxy that wouldn't break any
of our consumers, be they clients or servers.

I'm not convinced that large headers are an abuse of the protocol, btw.
There were some uses that I had to shake my head at and admit that there
weren't many other reasonable ways around it, e.g. clearing out all
possible permutations of all cookie-names, so that an auth cookie could
actually be successfully registered.

Certainly, that particular problem could be solved in a different way with
HTTP/2, but it would require changing other semantics, and would require
the server to realize there was a difference, which would cause deployment
headaches, etc. For all I know this has been fixed by additions to HTTP of
which I'm unaware.

I'll note that it is definitely a rare case, but when I saw it used, it was
also important for user interaction (else one would have to somehow
communicate to the user that they'd have to blow away their cache).
In cases where it is unexpected, I'd expect an endpoint to take action to
shutdown the stream. Attacks, whether malicious or not, are a fact of life,
and it is good to be able to identify them and blow them away without
affecting other users overly much.

On Wed, May 28, 2014 at 12:18 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> On May 28, 2014, at 8:40 PM, Roberto Peon <grmocg@gmail.com> wrote:
> The DoS surface with HTTP headers is not increased over HTTP/1 (which also
> would suffer from a requirement to tear down the transport when that kind
> if thing happens, unlike HTTP2).
> I believe I've mentioned before seeing rare, but multi-Mb headers in the
> past. We had, before that experience, amusingly assumed that 16k was enough
> for anyone, and were wrong by orders of magnitude.
> So I’m wondering. Some of us (not all) seem to be OK with telling some use
> cases to stick with HTTP/1, like printing or IoT or many of the other
> places that are outside HTTP/2 “design space”. Why are we going to such
> lengths to support this abuse of the protocol. Is it just because HTTP/1
> allows it?
> Yoav
Received on Wednesday, 28 May 2014 19:30:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC