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

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Tue, 01 March 2016 14:12 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6731A8714 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 1 Mar 2016 06:12:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzAKNNVPHiUe for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 1 Mar 2016 06:12:18 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB2C1A877C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 1 Mar 2016 06:12:18 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aakzK-0006DO-0t for ietf-http-wg-dist@listhub.w3.org; Tue, 01 Mar 2016 14:09:22 +0000
Resent-Message-Id: <E1aakzK-0006DO-0t@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1aakzE-0006Cb-Mr for ietf-http-wg@listhub.w3.org; Tue, 01 Mar 2016 14:09:16 +0000
Received: from raoul.w3.org ([128.30.52.128]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1aakzD-0004ot-7r for ietf-http-wg@w3.org; Tue, 01 Mar 2016 14:09:16 +0000
Received: from homard.platy.net ([80.67.176.7] helo=[192.168.1.40]) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1aakzC-00007J-K1 for ietf-http-wg@w3.org; Tue, 01 Mar 2016 14:09:14 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: text/plain; charset="us-ascii"
To: Mark Nottingham <mnot@mnot.net>
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
In-Reply-To: <20160301050755.8E4D9365C@welho-filter2.welho.com>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Tue, 01 Mar 2016 05:23:21 +0000
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP WG <ietf-http-wg@w3.org>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Content-Transfer-Encoding: 7bit
Resent-Date: Tue, 01 Mar 2016 15:09:10 +0100
Message-Id: <20160301052245.D97763DF4@welho-filter4.welho.com>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
References: <8AF0B2F7-561F-464B-840A-1F1B61F8370F@mnot.net> <20160301050755.8E4D9365C@welho-filter2.welho.com>
Resent-To: ietf-http-wg@w3.org
X-Mailer: Apple Mail (2.3112)
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, AWL=-2.256, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: maggie.w3.org 1aakzD-0004ot-7r da8ac567cad1505e6c9478830ee1af78
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-nottingham-proxy-explanation-00.txt
Archived-At: <http://www.w3.org/mid/20160301052245.D97763DF4@welho-filter4.welho.com>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31130
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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