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

Re: h2 padding

From: Brian Smith <brian@briansmith.org>
Date: Wed, 3 Sep 2014 15:40:56 -0700
Message-ID: <CAFewVt6kfw+PJzR-nsZoj1HWKYM22thMvq9gdk2OUPWDacY=JQ@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Greg Wilkins <gregw@intalio.com>, Jason Greene <jason.greene@redhat.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Sep 3, 2014 at 3:30 PM, Roberto Peon <grmocg@gmail.com> wrote:
> Truthfully, many folks who write applications will not think about this kind
> of thing, and providing something which does handle this for them
> automatically is likely quite a bit better than nothing.
> Sometimes (reverse) proxies are called into the picture to help out with
> some of these issues.
> In such cases, having a mechanism that allows a proxy to manipulate the data
> on the wire (likely with simple settings/rules for that
> application/product/endpoint) with a guarantee that it is not affecting an
> accidental semantic change is useful.

Roberto, I agree with everything that you said. However, in practice
almost every application has to deal with HTTP/1.1 clients and/or
HTTP/1.1 proxies, so it seems like they need to find a solution above
or below the HTTP layer for these problems, for the foreseeable

Process-wise, are there any interoperable implementations of the
padding feature that actually do something useful (i.e. using it for
real security), even as a proof of concept? I think there may be a
real gap between the theoretical benefits of having a padding
construct in HTTP/2 vs. the practical uselessness of it and/or its
unproven safety properties

Received on Wednesday, 3 September 2014 22:41:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC