Re: [hybi] [Technical Errata Reported] RFC6455 (5453)

Andy Green <andy@warmcat.com> Wed, 08 August 2018 16:50 UTC

Return-Path: <andy@warmcat.com>
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 41F59130EB2 for <hybi@ietfa.amsl.com>; Wed, 8 Aug 2018 09:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 JALYZAd5k7qZ for <hybi@ietfa.amsl.com>; Wed, 8 Aug 2018 09:50:10 -0700 (PDT)
Received: from warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A749E130EDA for <hybi@ietf.org>; Wed, 8 Aug 2018 09:50:09 -0700 (PDT)
Date: Thu, 09 Aug 2018 00:49:03 +0800
User-Agent: K-9 Mail for Android
In-Reply-To: <20180808134110.41FF7B80B0C@rfc-editor.org>
References: <20180808134110.41FF7B80B0C@rfc-editor.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: hybi@ietf.org, RFC Errata System <rfc-editor@rfc-editor.org>, ifette+ietf@google.com, Alexey.Melnikov@isode.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com
CC: julian.reschke@gmx.de,rfc-editor@rfc-editor.org
From: Andy Green <andy@warmcat.com>
Message-ID: <711770E5-8B23-4B32-BABE-3B0BE5EEFA31@warmcat.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/S6CKuV07tjiYCwSwyTsw-rIgu1k>
X-Mailman-Approved-At: Wed, 08 Aug 2018 20:36:31 -0700
Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (5453)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 08 Aug 2018 16:50:13 -0000


On August 8, 2018 9:41:10 PM GMT+08:00, RFC Errata System <rfc-editor@rfc-editor.org>; wrote:
>The following errata report has been submitted for RFC6455,
>"The WebSocket Protocol".
>
>--------------------------------------
>You may review the report below and at:
>http://www.rfc-editor.org/errata/eid5453
>
>--------------------------------------
>Type: Technical
>Reported by: Julian Reschke <julian.reschke@gmx.de>;
>
>Section: 4.1
>
>Original Text
>-------------
>   2.  If the response lacks an |Upgrade| header field or the |Upgrade|
>       header field contains a value that is not an ASCII case-
>       insensitive match for the value "websocket", the client MUST
>       _Fail the WebSocket Connection_.
>
>Corrected Text
>--------------
>   2.  If the response lacks an |Upgrade| header field or the |Upgrade|
>       header field contains a value that does not match "WebSocket",
>       the client MUST _Fail the WebSocket Connection_.
>
>Notes
>-----
>HTTP upgrade tokens are case-sensitive, and the token registered by RFC
>6455 is "WebSocket" (see
><https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml>).
>Examples should be adjusted accordingly.

I didn't see where registry entries are defined to be case sensitive.  RFC7230 8.6.1 doesn't seem to tell it either.

Assuming it's right, I think practically, this can't reasonably be 'fixed' in real-world RFC6455 implementations.

The receivers of the header (both clients and servers send and receive it) will mostly be okay, since they were warned to be on the lookout for case variations.

But I would guess 99% of senders of the upgrade header for RFC6455 responded to the existing text by issuing the specific string 'websockets' today.

With the first proposed change all those clients and servers (more or less all existing implementations) become noncompliant, which can't be the right way.

The second proposed way, with some case variations in the registry and some not, the conflict is not really solved.

Since this is a 'technical issue' in the sense the conflict is between RFC6455 text and the house rules of the registry, it can also be solved by the registry adding a note the "WebSockets" entry covers all case variations, can't it?  It's not like with the 5 or whatever entries in the registry to date, anyone was about to register 'weBsocKets'.  Or the registry can clearly state that all entries cover all case variations...

-Andy

>If stricter checks actually break the protocol, an alternative would be
>to register more variants of the token, such as "websocket".
>
>Instructions:
>-------------
>This erratum is currently posted as "Reported". If necessary, please
>use "Reply All" to discuss whether it should be verified or
>rejected. When a decision is reached, the verifying party  
>can log in to change the status and edit the report, if necessary. 
>
>--------------------------------------
>RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17)
>--------------------------------------
>Title               : The WebSocket Protocol
>Publication Date    : December 2011
>Author(s)           : I. Fette, A. Melnikov
>Category            : PROPOSED STANDARD
>Source              : BiDirectional or Server-Initiated HTTP APP
>Area                : Applications
>Stream              : IETF
>Verifying Party     : IESG
>
>_______________________________________________
>hybi mailing list
>hybi@ietf.org
>https://www.ietf.org/mailman/listinfo/hybi