- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Mon, 24 Feb 2014 11:17:08 +0100
- To: "William Chan (陈智昌)" <willchan@chromium.org>
- Cc: "Mark Nottingham" <mnot@mnot.net>, "Salvatore Loreto" <salvatore.loreto@ericsson.com>, "Peter Lepeska" <bizzbyster@gmail.com>, "Paul Hoffman" <paul.hoffman@gmail.com>, "Patrick McManus" <pmcmanus@mozilla.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
Le Lun 24 février 2014 07:35, William Chan (陈智昌) a écrit : > On Sun, Feb 23, 2014 at 10:31 PM, Mark Nottingham <mnot@mnot.net> wrote: >> >> On 20 Feb 2014, at 11:40 am, William Chan (陈智昌) <willchan@chromium.org> >> wrote: >> >>> Let's be clear, these are two different things. There's "secure proxy" >>> which is securing the connection between the proxy and the client. I'm >>> supportive of standardizing this. >> >> There seems to be a reasonable amount of support for this, and no >> dissent that I've heard. >> >> What needs to be specified here? We don't say much about proxies yet. I >> suppose we might need something like RFC2818 for secure proxies, but >> that seems somewhat straightforward, and it might be better for that to >> happen in the TLS WG (indeed, our charter pretty much says so). > > I don't think that there's anything HTTP/2 specific about "secure" > proxies. Proxy dialog will necessarily will be a dialect of http2. Or do you want to force every http2 implementer to code a second protocol with no relationship to http every time they have to deploy on proxified networks? And proxy dialog is more than "proxy here, connect". Sure it's not a lot more, but that's the difference between smooth operation and all the weird failure modes we get in http1 because the proxy part has been underspecified. Please to not make this mistake again. Regards, -- Nicolas Mailhot
Received on Monday, 24 February 2014 10:17:57 UTC