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: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>
Message-Id: <20160301050755.8E4D9365C@welho-filter2.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

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
Received on Tuesday, 1 March 2016 14:08:59 UTC

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