- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Tue, 01 Mar 2016 05:08:28 +0000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP WG <ietf-http-wg@w3.org>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
> At the end of the day, an intercepting proxy can already inject > anything into an unencrypted payload anyway, so I'm not sure this use > case is going to be interesting. > > I'm sure some intercepting proxy folks would like to show something > like this to the user for an encrypted stream, but that seems well out > of scope for this spec. Anyway, having a mechanism for the proxy to > talk to the user when it's legitimately configured instead of > intercepting might encourage more people to deploy non-intercepting > proxies :) > > So, I think I'll adjust the language in the draft to make this > specific to CONNECT. This is only for https ? Otherwise when browser is configured to use proxy and URL is http, browser do not use CONNECT but original http -method (GET and so on). Given url just is absolute. Of course on http -case browser already shows error response (when it is html). It is strange if browser shows proxy response when it is text/html, but not if it is application/proxy-explanation+json ( That is situation when that media type is restricted to CONNECT and browser shows other error responses anyway for http: -urls when CONNECT is not used. ) You perhaps want limit that for CONNECT -usage when url is https -- And no limitation when url is http (encrypted (i.e. Alt-Svc) or not) ? / Kari Hurtta ( just reading https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/index.html )
Received on Tuesday, 1 March 2016 14:08:59 UTC