W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: New Version Notification for draft-nottingham-proxy-explanation-00.txt

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>
Message-Id: <20160301052245.D97763DF4@welho-filter4.welho.com>
>> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC