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

[Kari Hurtta <[e-mail]>]

> 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
 )