- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 12 May 2015 19:34:18 +1200
- To: Willy Tarreau <w@1wt.eu>, Martin Thomson <martin.thomson@gmail.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 12/05/2015 5:06 p.m., Willy Tarreau wrote: > On Mon, May 11, 2015 at 05:07:31PM -0700, Martin Thomson wrote: >> On 11 May 2015 at 16:18, Amos Jeffries wrote: >>> I am more than a little surprised to find not one single mention of >>> proxy or cache middleware types or interoperability with them anywhere >>> within this document. Despite clear implications that it is intended for >>> use to secure data within CDN and other plain-text HTTP environments. >> >> Cleartext HTTP use cases are actually not intended for this, though >> I'm not opposed to adding any that make sense. > > Well, you see, I've met people who designed and deployed their in-house > payload encryption mechanism in a banking environment where using plain > text for headers is mandatory to provide request routing capabilities > without giving the ability to decrypt data between the two extremities. > In fact many people use HTTP as a service-aware transport protocol on > top of TCP. > > I can predict that you'll get requests for encrypting or at least signing > *some* header fields because these people had to do that when facing the > same use cases :-) My take on that is that they should be able to use MIME syntax (or equivalent) within the encrypted payload to transmit additional object related headers. The very act of encrypting any headers explicitly puts them out of scope of the transfer protocol (HTTP). So we dont need to care and should leave it undefined in this spec. Amos
Received on Tuesday, 12 May 2015 07:34:54 UTC