Re: [hybi] proxy & ENABLE_UPGRADE SETTINGS | Re: Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

Amos Jeffries <squid3@treenet.co.nz> Sat, 11 November 2017 14:17 UTC

Return-Path: <squid3@treenet.co.nz>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEC61200E5 for <hybi@ietfa.amsl.com>; Sat, 11 Nov 2017 06:17:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 JKMkPQ0hqrEZ for <hybi@ietfa.amsl.com>; Sat, 11 Nov 2017 06:17:09 -0800 (PST)
Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id BEFF412009C for <hybi@ietf.org>; Sat, 11 Nov 2017 06:17:07 -0800 (PST)
Received: from [192.168.137.92] (unknown [121.98.43.66]) by treenet.co.nz (Postfix) with ESMTPA id 1FC00660057; Sun, 12 Nov 2017 03:17:02 +1300 (NZDT)
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP Working Group <ietf-http-wg@w3.org>
Cc: HYBI Working Group <hybi@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>
References: <e7420a25-7f57-8849-9820-ccc33053bd97@treenet.co.nz> <20171111091949.5F294B51FC@welho-filter2.welho.com>
From: Amos Jeffries <squid3@treenet.co.nz>
Message-ID: <d5edca63-b782-9c57-f169-478b590ccf35@treenet.co.nz>
Date: Sun, 12 Nov 2017 03:17:01 +1300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171111091949.5F294B51FC@welho-filter2.welho.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/NzfScfEV_e0vvShr8CmExsi2NRE>
Subject: Re: [hybi] proxy & ENABLE_UPGRADE SETTINGS | Re: Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Nov 2017 14:17:11 -0000

On 11/11/17 22:19, Kari Hurtta wrote:
>>      SETTINGS   ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) from server
>>      end of connection to client end of connection tells on that case
>>
>>      that server end of connection understand
>>               :upgrade
>>      pseudo header.
>>
>>      It tells nothing about that what is behind of that server end of
>>      connection.
>>
>>      Only after request is sent, http response tells if that authority
>>      and path supporting that upgrade. Error is reported as http status code.
>>
>>      I see that reverse proxy can send SETTINGS   ENABLE_UPGRADE (or
>>      ENABLE_CONNECT_PROTOCOL)
>>      even when it does not konw if next hop supports that. Support
>>      of next hop or origin server is reported by when that protocol
>>      is triedm failure is reported on http status code.
> 
> Amos Jeffries <squid3@treenet.co.nz>; wrote:
> 
>> A proxy that sends that ENABLE_UPGRADE is guaranteeing that it *will*
>> service the upgrade and handle the resulting traffic syntax. By itself
>> if necessary.
> 
> I ligthly disagreed.
> 
> ENABLE_UPGRADE just tells that :upgrade is not considered to
> be error which causes stream error of type PROTOCOL_ERROR
> emitted and tells possible full duplex handling (as was on
> :method = CONNECT).
> 
> You can also try Upgrade: on HTTP/1.1 and server or proxy
> have permission to ignore it.   Upgrade is just suggestion
> from client.

If ":upgrade" has the same optional nature as Upgrade did there is zero 
point in creating it. Just use the existing Upgrade header in the 
HEADERS frame. That does not require any negotiation.


The whole point of SETTINGS is to promise the recipient of that frame 
that the things mentioned in it will work. No maybes or guessing.

This guarantee provided by SETTINGS is one of the ways HTTP/2 improves 
over HTTP/1.1. No more sending maybe-ignored headers and hoping for 
success a few RTT later. The client can know up front whether that 
connection is a usable channel for the negotiable feature or not.

...

> 
>> In the general case a proxy that negotiates a SETTING it cannot
>> guarantee support for is broken. It must instead negotiate a SETTINGS
>> without the feature and re-negotiate with another SETTINGS later when it
>> has better information.
> 
> / Kari Hurtta
> 
>