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