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

[Andy Green <[e-mail]>]

On 1/30/22 06:07, David Jarry wrote:

>> 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?

In ws, messages come with an indication they are UTF-8 TEXT (started 
with opcode 1) or BINARY (opcode 2).  So "receives a binary message" 
isn't an ambiguous thing in ws, the server will always know clearly if 
he got the type he wasn't expecting.

> 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…).

It is simple since it tells you if it is BINARY or TEXT explicitly.  Ws 
doesn't attempt to define payload semantics so it's not the right layer 
to define what's wrong with them.  The server can send arbitrary 
diagnostic payload in the CLOSE frame extra data to help with analysis.

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

First code is generally for "data it cannot accept", the example given 
is the case it was sent the wrong one of BINARY or TEXT message.

Second one is for if you see a TEXT message that violated the specific 
requirement that it must contain valid UTF-8.  It's written generally 
but IIRC TEXT + UTF-8 is the only time ws talks about judging payload 
contents themselves.

> 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)?

It doesn't say that they shouldn't, so there is no conflict with doing 
so.  It would indeed be better if it did say they MUST.

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

I don't disagree with the observation, but it's like that because ws was 
defined as an upgrade protocol from http, which has this schism 
thoroughly baked in.

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

He's not "forbidden to be behind a gateway or proxy", he just isn't 
given an explicit way to explain he's closing from shenanigans due to that.

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

Well, I guess it could be useful.

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

I guess if you have 1014, this is also useful.

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

Timeouts may not necessarily want to present at ws layer, eg, whatever 
timed out might be retryable inside the ws connection session without 
terminating and re-establishing it.  So I think this is of limited use.

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

The idea of the subprotocol naming is to contain the necessary 
versioning cleanly.

https://datatracker.ietf.org/doc/html/rfc6455#section-1.9

> 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)!

Unless I miss your point, again subprotocols are designed to absorb this 
kind of problem (and allow the client to propose multiple supported 
versions in one step).

-Andy