Codice di risposta HTTP quando richiesto il sottoprotocollo websocket non è supportato/riconosciuto

Question

Quando si aggiorna una connessione HTTP a un websocket, è possibile fornire uno o più sottoprotocolli nell'intestazione HTTP facoltativa 'Sec-WebSocket-Protocol'.

Se il server accetta uno dei sottoprotocolli risponde con il codice di risposta HTTP 101 ("Protocolli di commutazione HTTP/1.1 101") e include l'intestazione HTTP "Sec-WebSocket-Protocol" che indica il sottoprotocollo selezionato.

Ma come deve il server gestire correttamente un subprotocollo sconosciuto/non supportato?

Se ciò dovesse avvenire "all'interno" della connessione HTTP - mediante l'uso di un codice di risposta HTTP?

Oppure la connessione deve essere aggiornata a una websocket e immediatamente chiusa dal server inviando un 'Chiudi frame' con alcuni dei codici di stato Websocket predefiniti?

Che cosa dice la RFC6455? Non posso arrivare a una conclusione. Come vengono gestite le implementazioni dei server esistenti?

saluti /Per/

Answer 1

Da una breve sguardo alla RFC 6455, credo che il WebSocket subprotocol è opzionale e negoziata. Nella sezione 4.2.2, sotto "Rquirements server":

/subprotocol/ 
     Either a single value representing the subprotocol the server 
     is ready to use or null. The value chosen MUST be derived 
     from the client's handshake, specifically by selecting one of 
     the values from the |Sec-WebSocket-Protocol| field that the 
     server is willing to use for this connection (if any). If the 
     client's handshake did not contain such a header field or if 
     the server does not agree to any of the client's requested 
     subprotocols, the only acceptable value is null. The absence 
     of such a field is equivalent to the null value (meaning that 
     if the server does not wish to agree to one of the suggested 
     subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol| 
     header field in its response). The empty string is not the 
     same as the null value for these purposes and is not a legal 
     value for this field. The ABNF for the value of this header 
     field is (token), where the definitions of constructs and 
     rules are as given in [RFC2616]. 

Il server non deve inviare un'intestazione di risposta subprotocol con un valore diverso da 'null' se non era d'accordo di utilizzare il protocollo secondario con il cliente, ed è la responsabilità del cliente di continuare o terminare la connessione a quel punto.

Answer 2

L'intero punto di WebSocket è di utilizzare WebSocket per eseguire un protocollo specifico dal client al server. Ma il client e il server devono conoscere il protocollo in modo che entrambe le parti sappiano cosa fare con i messaggi WS in arrivo. La gestione dei messaggi WS non è diversa da ciò che si farebbe a livello di TCP. Non è necessario utilizzare il campo del protocollo, è rilevante solo se si desidera applicare la compatibilità.

Per il server Kaazing, forniamo librerie di protocollo specifiche che si trovano sopra il livello Websocket di base. Puoi anche trovare varie librerie di protocolli su Github. Ad eccezione della stretta di mano, tutto il resto è il modo in cui lo gestiresti con TCP. Elaborate i messaggi Websocket e provate a decodificare il protocollo. Il campo del protocollo nell'handshake dovrebbe essere usato per assicurarsi che la libreria sia effettivamente la libreria di protocollo corrispondente. Ad esempio, se il mio server parla di STOMP e cerco di connettermi con il mio client e voglio parlare di STOMP, la mia libreria STOMP dovrebbe controllare il campo del protocollo per accertarsi che corrisponda. Gli endpoint possono indicare nell'ordine di preferenza, ad esempio, che possono parlare AMQP 0.9 e AMQP 1.0 e scegliere AMQP 1.0 se entrambi sono disponibili. Se uno degli endpoint non parla nessuno dei protocolli che l'altro capo può parlare, può restituire null e quindi la connessione viene interrotta.