Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Responding to a WebSocket upgrade request

Tags:

I have a WebSocket server that gets WebSocket upgrade requests from different clients. Based on the query or path params of the request, sometimes the server needs to reject these upgrade requests. The server needs to cancel the handshake not because it does not support the protocol or because of a protocol violation by the client but because of other reasons as mentioned.

Is there a standard status code to respond with in this scenario? The specification does not seem to define a response status code for this case. Here also it is mentioned that if it is a protocol violation by the client the server should respond with a "400 Bad Request" but no mention is made on the response to be sent if the server simply wants to cancel the handshake for some other reason.

Can the server choose the respond with any status code without violating the protocol?

like image 867
Riyafa Abdul Hameed Avatar asked May 10 '18 05:05

Riyafa Abdul Hameed


People also ask

Is WebSocket request a response?

The WebSocket protocol is not designed around request-response. Messages may be sent from either end of the connection at any time, and there is no native support for one message to indicate it is related to another.

How do I update WebSocket client?

Upgrading to a WebSocket connectionThe WebSocket() constructor does all the work of creating an initial HTTP/1.1 connection then handling the handshaking and upgrade process for you. Note: You can also use the "wss://" URL scheme to open a secure WebSocket connection.


1 Answers

For those urls the server is allowed to response as if it does not know anything about WebSockets. So a plain 400 error is perfectly fine. And you are not required to display any further informations in the body, or add any further headers.

And in larger server setups, there is usually a reverse proxy that accepts every incoming request, and forwards this requests to the corresponding applications based on the URL, and it would be a real problem if the HTTP based protocols would require that this reverse proxy had to know all protocols.

Once the client's opening handshake has been sent, the client MUST wait for a response from the server before sending any further data. The client MUST validate the server's response as follows:

  1. If the status code received from the server is not 101, the client handles the response per HTTP [RFC2616] procedures.

The 400 error is described as:

6.5.1. 400 Bad Request

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

Which would also match a upgrade request for an url that does not support that protocol.

The 4xx error codes are defined as this:

6.5. Client Error 4xx

The 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included representation to the user.

So a response with 400 status and no further informations is valid, because those are optional.

like image 63
t.niese Avatar answered Oct 04 '22 16:10

t.niese