[hybi] Several questions/proposals about WebSocket Close Status Codes

David Jarry <hybi@melnofil.fr> Sun, 30 January 2022 06:07 UTC

Return-Path: <hybi@melnofil.fr>
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 0A4C73A187E for <hybi@ietfa.amsl.com>; Sat, 29 Jan 2022 22:07:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 XiICeJ6DCxcu for <hybi@ietfa.amsl.com>; Sat, 29 Jan 2022 22:07:11 -0800 (PST)
Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63AEC3A187D for <hybi@ietf.org>; Sat, 29 Jan 2022 22:07:09 -0800 (PST)
Received: (Authenticated sender: hybi@melnofil.fr) by mail.gandi.net (Postfix) with ESMTPSA id 266A4240003 for <hybi@ietf.org>; Sun, 30 Jan 2022 06:07:06 +0000 (UTC)
Content-Type: multipart/alternative; boundary="------------uM215OUhfepi3UsCn0SUPfha"
Message-ID: <f9ca533c-7cfb-9079-26c1-6f99eec529a2@melnofil.fr>
Date: Sun, 30 Jan 2022 07:07:06 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
From: David Jarry <hybi@melnofil.fr>
To: hybi@ietf.org
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/n7zR1ZzciWC7g46CzLIMgKMebb8>
Subject: [hybi] Several questions/proposals about WebSocket Close Status Codes
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 30 Jan 2022 06:11:34 -0000

Hello,

I am a contributor to Wikipedia FR, I have several questions/proposals 
about WebSocket Close Status Codes.


I/

> RFC : 1003 indicates that an endpoint is terminating the connection 
> because it has received a type of data it cannot accept (e.g., an 
> endpoint that understands only text data MAY send this if it receives 
> a binary message).
> IANA : Unsupported Data.
>
> RFC : 1007 indicates that an endpoint is terminating the connection 
> because it has received data within a message that was not consistent 
> with the type of the message (e.g., non-UTF-8 data within a text message).
> IANA : Invalid frame payload data.

I don't understand how to choose between these two codes: How does a 
server expecting UTF-8 text know the difference between binary input and 
non-UTF-8 input?

It would be much simpler if one code corresponded to "I expect XML and I 
received JSON" (type error, encoding error, parsing error…) and if the 
other code corresponded to "I expect a JSON object ({}) and I received a 
JSON array ([])" (value error, precondition fail on data, wrong content…).


So if a server expects UTF-8 text:

  * The first code is returned if UTF-8 decoding fails (it doesn't
    matter if the input is binary or a nearly UTF-8 text).
  * The second code is returned if the text uses Egyptian hieroglyphs
    when an English text was expected.


II/

>  IANA 1014 : The server was acting as a gateway or proxy and received 
> an invalid response from the upstream server. This is similar to 502 
> HTTP Status Code.
> RFC : Status codes in the range 4000-4999 are reserved for private use 
> and thus can't be registered. Such codes can be used by prior 
> agreements between WebSocket applications. The interpretation of these 
> codes is undefined by this protocol. IANA : Reserved for Private Use.

Since the code 1014 admits the existence of gateway and proxy, shouldn't 
it be specified somewhere that the intermediate servers MUST pass 
without modifications any code in the range 4000-4999 that it does not 
understand, so that the agreement can be directly established between 
the end server and the end client (dispite of gateway and proxy)?


III/

Unlike HTTP, communication is two-way, but many codes assume that there 
is a service, a server, and a client. For certain uses, it may be 
interesting to use the WebSocket protocol between two servers (peer to 
peer). For example if a server on a local network wants to communicate 
with an external server through a Firewall which only accepts port 80 in 
both directions, then WebSocket makes it possible to create sockets in 
both directions even through an HTTPd. Everything should be done to 
reduce the difference between a server and a client (once the connection 
is established, think of it like peers).

> IANA 1014 : The server was acting as a gateway or proxy and received 
> an invalid response from the upstream server. This is similar to 502 
> HTTP Status Code.

Must be "Gateway or Proxy Error"! Please authorize a client to send this 
code. I don't understand why a client is forbidden to be behind a 
gateway or a proxy.

> IANA 1012 : Service Restart

Must be "Restart"! Please authorize a client to send this code. Maybe 
the server will decide to keep certain things cached (unlike code 1000 
where the server can destroy all its caches).


IV/

Proposals (codes for timeouts and version checks):

Gateway or Proxy Timeout:
The server was acting as a gateway or proxy and did not receive a timely 
response from the upstream server. This is similar to 504 HTTP Status Code.

Timeout:
A generic status code that can be returned when a timeout has occurred, 
meaning that the purpose for which the connection was established was 
not been fulfilled (something took too long).

Deprecated:
Please update. Even a client can send this code and try another server, 
a warning can be written in the server log.

Not Implemented:
I'm not updated.A client can reboot with backwards compatibility enabled 
or connect to another server. A server can treat this request as a 1012 
code, except that the last request was not understood (e.g., the 
clientbrowser should reload the page, then the serveur send back the 
last message)!


Cordially,

David Jarry.