- From: Brian Smith <brian@briansmith.org>
- Date: Wed, 3 Sep 2014 15:40:56 -0700
- 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 future. 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 Cheers, Brian
Received on Wednesday, 3 September 2014 22:41:27 UTC