- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Tue, 01 Mar 2016 05:23:21 +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) ? Or limit to case where proxy is configured to be used and http error status is given (not succeed code). When CONNECT is not used (unencrypted http) and browser is configured to proxy, browser does not know is response from original server or from proxy. ( If application/proxy-explanation+json is not shown for http -urls in case of non-intercepting proxies, it is not really encouraging. ) If proxy uses application/proxy-explanation+json for CONNECT, then it make sense to use application/proxy-explanation+json for other types (specially GET) also (if browser indicates that it supports application/proxy-explanation+json ) because that unifies user experiense between http and https -urls. ( when https error response proxy can not really emulate same experience ) / Kari Hurtta
Received on Tuesday, 1 March 2016 14:09:16 UTC