Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Fri, 10 November 2017 16:50 UTC

Return-Path: <hurtta@siilo.fmi.fi>
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 DC2531289C3 for <hybi@ietfa.amsl.com>; Fri, 10 Nov 2017 08:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 zHFnRMulkz2J for <hybi@ietfa.amsl.com>; Fri, 10 Nov 2017 08:50:24 -0800 (PST)
Received: from smtpVgate.fmi.fi (smtpvgate.fmi.fi [193.166.223.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22411279E5 for <hybi@ietf.org>; Fri, 10 Nov 2017 08:50:23 -0800 (PST)
Received: from souk.fmi.fi (souk.fmi.fi [193.166.211.113]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id vAAGoDQ5004840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Nov 2017 18:50:13 +0200
Received: from shell.siilo.fmi.fi by souk.fmi.fi with ESMTP id vAAGoC0x027831 ; Fri, 10 Nov 2017 18:50:13 +0200
Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id vAAGoCLa026167 ; Fri, 10 Nov 2017 18:50:12 +0200
Received: by shell.siilo.fmi.fi id vAAGoBln026166; Fri, 10 Nov 2017 18:50:11 +0200
Message-Id: <201711101650.vAAGoBln026166@shell.siilo.fmi.fi>
In-Reply-To: <CANatvzya831tQdWsjpiwdF537jVqZYCQpi3aFHLdQoGjShcCRw@mail.gmail.com>
References: <CAD3-0rPPGx4k+ksk-QDnNhnescfPHiYSJ-z2AQeMR2=khaO_HQ@mail.gmail.com> <20171110061456.1349EB532F@welho-filter2.welho.com> <CANatvzya831tQdWsjpiwdF537jVqZYCQpi3aFHLdQoGjShcCRw@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 10 Nov 2017 18:50:11 +0200 (EET)
Sender: hurtta@siilo.fmi.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Wenbo Zhu <wenboz@google.com>, Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-Mailer: ELM [version ME+ 2.5 PLalpha46]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20171110/28481/01
X-Filter: smtpVgate.fmi.fi: ID 28483/01, 1 parts scanned for known viruses
X-Filter: souk.fmi.fi: ID 117820/01, 1 parts scanned for known viruses
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Fri, 10 Nov 2017 18:50:13 +0200 (EET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/tjFsEWgAmNnalFfvrdaSvZ_Vz2o>
Subject: Re: [hybi] 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: Fri, 10 Nov 2017 16:50:27 -0000

Kazuho Oku <kazuhooku@gmail.com>;: (Fri Nov 10 09:05:20 2017)
> 2017-11-10 15:14 GMT+09:00 Kari Hurtta <hurtta-ietf@elmme-mailer.org>;:
> >> Therefore the explicit tunneling mechanism is
> >> necessary to signal to proxies/frameworks that a full-duplex byte-stream is
> >> being tunneled as a http/2 stream.
> >
> >>> Request:
> >>>   :method: GET
> >>>   :scheme: https
> >>>   :authority: server.example.com
> >>>   :path: /chat
> >>>   :upgrade: websocket
> >
> > 8.1.2.1.  Pseudo-Header Fields
> > https://tools.ietf.org/html/rfc7540#section-8.1.2.1
> >
> > states
> >
> > --------
> >
> >    Pseudo-header fields are only valid in the context in which they are
> >    defined.  Pseudo-header fields defined for requests MUST NOT appear
> >    in responses; pseudo-header fields defined for responses MUST NOT
> >    appear in requests.  Pseudo-header fields MUST NOT appear in
> >    trailers.  Endpoints MUST treat a request or response that contains
> >    undefined or invalid pseudo-header fields as malformed
> >    (Section 8.1.2.6).
> >
> > --------
> >
> > Then that ":upgrade" works as explicit tunneling mechanism, IF you can trust
> > that response is treated as mailformed (stream error of type PROTOCOL_ERROR)
> > when proxies/frameworks does not subscribe that tunneling mechanism.
> >
> > Can you trust that?
> 
> Note that we would be doing negotiation beforehand using a SETTINGS
> parameter. Otherwise, a client cannot send a request with `:upgrade:`
> pseudo header.
> 
> I believe that a successful negotiation would be sufficient to
> guarantee that the `:upgrade:` response header will be recognized as a
> signal (or a 101 status code as a signal).

Yes, 

5.5.  Extending HTTP/2
https://tools.ietf.org/html/rfc7540#section-5.5

-----------------
"   Extensions that could change the semantics of existing protocol
"   components MUST be negotiated before being used. 
-----------------

seems imply that :upgrade pseudo header maut be negotiated.

SETTINGS is one possibility:

----------------
"   This document doesn't mandate a specific method for negotiating the
"   use of an extension but notes that a setting (Section 6.5.2) could be
"   used for that purpose. 
----------------

Seems that existing of new pseudo header itself can not be used as
negotiation:

----------------
"   Extensions are permitted to use new frame types (Section 4.1), new
"   settings (Section 6.5.2), or new error codes (Section 7).  Registries
"   are established for managing these extension points: frame types
"   (Section 11.2), settings (Section 11.3), and error codes
"   (Section 11.4).
"
"   Implementations MUST ignore unknown or unsupported values in all
"   extensible protocol elements.  
----------------

/ Kari Hurtta

> 
> 
> 
> -- 
> Kazuho Oku