diff options
Diffstat (limited to 'files/de/websockets/writing_websocket_servers/index.html')
| -rw-r--r-- | files/de/websockets/writing_websocket_servers/index.html | 250 |
1 files changed, 250 insertions, 0 deletions
diff --git a/files/de/websockets/writing_websocket_servers/index.html b/files/de/websockets/writing_websocket_servers/index.html new file mode 100644 index 0000000000..031a2b832a --- /dev/null +++ b/files/de/websockets/writing_websocket_servers/index.html @@ -0,0 +1,250 @@ +--- +title: Writing WebSocket servers +slug: WebSockets/Writing_WebSocket_servers +translation_of: Web/API/WebSockets_API/Writing_WebSocket_servers +--- +<div>{{APIRef("Websockets API")}}</div> + +<p>E<span class="tlid-translation translation" lang="de"><span title="">in WebSocket-Server ist nichts anderes als eine Anwendung, die einen Port eines TCP-Servers überwacht, der einem bestimmten Protokoll folgt.</span> <span title="">Die Aufgabe, einen benutzerdefinierten Server zu erstellen, macht den Leuten Angst.</span> <span title="">Es kann jedoch unkompliziert sein, einen einfachen WebSocket-Server auf einer Plattform Ihrer Wahl zu implementieren.</span></span></p> + +<p><span class="tlid-translation translation" lang="de"><span title="">Ein WebSocket-Server kann in jeder serverseitigen Programmiersprache geschrieben werden, die dazu in der Lage ist</span></span>: <a href="https://en.wikipedia.org/wiki/Berkeley_sockets">Berkeley sockets</a>, siehe auch C(++), Python, <a href="/en-US/docs/PHP">PHP</a>, oder Serverseitiges<a href="/en-US/docs/Web/JavaScript/Server-Side_JavaScript"> JavaScript</a>.</p> + +<p><span class="tlid-translation translation" lang="de"><span title="">Dies ist kein Tutorial in einer bestimmten Sprache, sondern dient als Leitfaden, um das Schreiben Ihres eigenen Servers zu erleichtern.</span></span></p> + +<p><span class="tlid-translation translation" lang="de"><span title="">In diesem Artikel wird davon ausgegangen, dass Sie bereits mit der Funktionsweise von {{Glossary ("HTTP")}} vertraut sind und über ein moderates Programmiererlebnis verfügen.</span> <span title="">Abhängig von der Sprachunterstützung sind möglicherweise Kenntnisse über TCP-Sockets erforderlich.</span> <span title="">In diesem Handbuch wird das Mindestwissen dargestellt, das Sie zum Schreiben eines WebSocket-Servers benötigen.</span></span></p> + +<div class="note"> +<p><strong><u>Notiz</u>:</strong> <span class="tlid-translation translation" lang="de"><span title="">Lesen Sie die neueste offizielle WebSockets-Spezifikation, RFC 6455. Die Abschnitte 1 und 4-7 sind für Server-Implementierer besonders interessant.</span> <span title="">In Abschnitt 10 wird die Sicherheit erläutert, und Sie sollten sie unbedingt lesen, bevor Sie Ihren Server verfügbar machen.</span></span></p> +</div> + +<p><span class="tlid-translation translation" lang="de"><span title="">Ein WebSocket-Server wird hier auf sehr niedriger Ebene erklärt.</span> <span title="">WebSocket-Server sind häufig separate und spezialisierte Server (aus Gründen des Lastenausgleichs oder aus anderen praktischen Gründen). Daher verwenden Sie häufig einen Reverse-Proxy (z. B. einen normalen HTTP-Server), um WebSocket-Handshakes zu erkennen, vorzuverarbeiten und an diese Clients zu senden</span> <span title="">ein echter WebSocket-Server.</span> <span title="">Dies bedeutet, dass Sie Ihren Servercode nicht mit Cookie- und Authentifizierungshandlern (zum Beispiel) aufblähen müssen.</span></span></p> + +<h2 id="Der_WebSocket-Handshake"><strong><u><span class="tlid-translation translation" lang="de"><span title="">Der WebSocket-Handshake</span></span> </u></strong></h2> + +<p><span class="tlid-translation translation" lang="de"><span title="">Zunächst muss der Server mithilfe eines Standard-TCP-Sockets auf eingehende Socket-Verbindungen warten.</span> <span title="">Abhängig von Ihrer Plattform kann dies automatisch für Sie erledigt werden.</span> <span title="">Angenommen, Ihr Server überwacht example.com, Port 8000, und Ihr Socket-Server antwortet auf {{HTTPMethod ("GET")}} -Anfragen unter example.com/chat.</span></span></p> + +<div class="warning"> +<p><span class="tlid-translation translation" lang="de"><span title=""><u>Warnung</u>: Der Server überwacht möglicherweise jeden von ihm ausgewählten Port. Wenn er jedoch einen anderen Port als 80 oder 443 auswählt, kann es zu Problemen mit Firewalls und / oder Proxys kommen.</span> <span title="">Browser benötigen im Allgemeinen eine sichere Verbindung für WebSockets, obwohl sie möglicherweise eine Ausnahme für lokale Geräte bieten.</span></span></p> +</div> + +<p><span class="tlid-translation translation" lang="de"><span title="">Der Handshake ist das "Web" in WebSockets.</span> <span title="">Es ist die Brücke von HTTP zu WebSockets.</span> <span title="">Beim Handshake werden Details der Verbindung ausgehandelt, und jede Partei kann vor Abschluss zurücktreten, wenn die Bedingungen ungünstig sind.</span> <span title="">Der Server muss darauf achten, alles zu verstehen, was der Client verlangt, da sonst Sicherheitsprobleme auftreten können.</span></span></p> + +<div class="blockIndicator note"> +<p><span class="tlid-translation translation" lang="de"><span title=""><u>Tipp</u>: Die Anfrage-URL (/ Chat hier) hat in der Spezifikation keine definierte Bedeutung.</span> <span title="">Viele Benutzer verwenden es daher, damit ein Server mehrere WebSocket-Anwendungen verarbeiten kann.</span> <span title="">Zum Beispiel könnte example.com/chat eine Mehrbenutzer-Chat-App aufrufen, während /game auf demselben Server möglicherweise ein Multiplayer-Spiel aufruft.</span></span></p> +</div> + +<h3 id="Client_handshake_Anfrage">Client handshake Anfrage</h3> + +<p><span class="tlid-translation translation" lang="de"><span title="">Auch wenn Sie einen Server erstellen, muss ein Client den WebSocket-Handshake-Prozess starten, indem er den Server kontaktiert und eine WebSocket-Verbindung anfordert.</span> <span title="">Sie müssen also wissen, wie Sie die Anfrage des Kunden interpretieren.</span> <span title="">Der Client sendet eine ziemlich normale HTTP-Anfrage mit Headern, die so aussehen (die HTTP-Version muss 1.1 oder höher sein und die Methode muss GET sein):</span></span></p> + +<pre class="notranslate">GET /chat HTTP/1.1 +Host: example.com:8000 +<strong>Upgrade: websocket</strong> +<strong>Connection: Upgrade</strong> +Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== +Sec-WebSocket-Version: 13 + +</pre> + +<p><span class="tlid-translation translation" lang="de"><span title="">Der Client kann hier Erweiterungen und / oder Unterprotokolle anfordern.</span> <span title="">Einzelheiten finden Sie unter Sonstiges.</span> <span title="">Es können auch allgemeine Header wie {{HTTPHeader ("User-Agent")}}, {{HTTPHeader ("Referer")}}, {{HTTPHeader ("Cookie")}} oder Authentifizierungsheader vorhanden sein.</span> <span title="">Mach mit denen, was du willst;</span> <span title="">Sie beziehen sich nicht direkt auf das WebSocket.</span> <span title="">Es ist auch sicher, sie zu ignorieren.</span> <span title="">In vielen gängigen Setups hat sich bereits ein Reverse-Proxy mit ihnen befasst.</span></span></p> + +<div class="blockIndicator note"> +<p><span class="tlid-translation translation" lang="de"><span title=""><u>Tipp</u>: Alle Browser senden einen Origin-Header.</span> <span title="">Sie können diesen Header aus Sicherheitsgründen verwenden (nach demselben Ursprung suchen, automatisch zulassen oder ablehnen usw.) und eine 403 Forbidden senden, wenn Ihnen das, was Sie sehen, nicht gefällt.</span> <span title="">Seien Sie jedoch gewarnt, dass Nicht-Browser-Agenten einen gefälschten Ursprung senden können.</span> <span title="">Die meisten Anwendungen lehnen Anforderungen ohne diesen Header ab.</span></span></p> +</div> + +<p><span class="tlid-translation translation" lang="de"><span title="">Wenn ein Header nicht verstanden wird oder einen falschen Wert hat, sollte der Server eine {{HTTPStatus ("400")}} ("Bad Request")} Antwort senden und den Socket sofort schließen.</span> <span title="">Wie üblich wird möglicherweise auch der Grund angegeben, warum der Handshake im HTTP-Antworttext fehlgeschlagen ist, die Nachricht wird jedoch möglicherweise nie angezeigt (Browser zeigen sie nicht an).</span> <span title="">Wenn der Server diese Version von WebSockets nicht versteht, sollte er einen {{HTTPHeader ("Sec-WebSocket-Version")}} Header zurücksenden, der die Version (en) enthält, die er versteht.</span> <span title="">Im obigen Beispiel wird Version 13 des WebSocket-Protokolls angegeben.</span><br> + <br> + <span title="">Der interessanteste Header hier ist {{HTTPHeader ("Sec-WebSocket-Key")}}.</span> <span title="">Schauen wir uns das also als nächstes an.</span></span></p> + +<div class="note"> +<p><span class="tlid-translation translation" lang="de"><span title=""><u>Hinweis</u>: Normale HTTP-Statuscodes können nur vor dem Handshake verwendet werden.</span> <span title="">Nach erfolgreichem Handshake müssen Sie einen anderen Satz von Codes verwenden (definiert in Abschnitt 7.4 der Spezifikation).</span></span></p> +</div> + +<h3 id="Server_handshake_Antwort">Server handshake Antwort</h3> + +<p><span class="tlid-translation translation" lang="de"><span title="">Wenn der Server die Handshake-Anforderung empfängt, sollte er eine spezielle Antwort zurücksenden, die angibt, dass das Protokoll von HTTP zu WebSocket geändert wird.</span> <span title="">Dieser Header sieht ungefähr so aus (denken Sie daran, dass jede Headerzeile mit \ r \ n endet, und setzen Sie nach dem letzten ein zusätzliches \ r \ n, um das Ende des Headers anzuzeigen):</span></span></p> + +<pre class="notranslate"><strong>HTTP/1.1 101 Switching Protocols</strong> +Upgrade: websocket +Connection: Upgrade +<strong>Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= + +</strong></pre> + +<p><span class="tlid-translation translation" lang="de"><span title="">Darüber hinaus kann der Server hier über Erweiterungs- / Unterprotokollanforderungen entscheiden.</span> <span title="">Einzelheiten finden Sie unter Sonstiges.</span> <span title="">Der Sec-WebSocket-Accept-Header ist wichtig, da der Server ihn von dem {{HTTPHeader ("Sec-WebSocket-Key")}} ableiten muss, den der Client an ihn gesendet hat.</span> <span title="">Verketten Sie dazu den Sec-WebSocket-Key des Clients und die Zeichenfolge "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" (es handelt sich um eine "magische Zeichenfolge"), nehmen Sie den SHA-1-Hash des Ergebnisses und geben Sie den base64 zurück</span> <span title="">Codierung dieses Hashs.</span></span></p> + +<div class="note"> +<p><span class="tlid-translation translation" lang="de"><span title=""><strong><u>Hinweis</u></strong>: Dieser scheinbar überkomplizierte Prozess ist vorhanden, sodass für den Client offensichtlich ist, ob der Server WebSockets unterstützt.</span> <span title="">Dies ist wichtig, da Sicherheitsprobleme auftreten können, wenn der Server eine WebSockets-Verbindung akzeptiert, die Daten jedoch als HTTP-Anforderung interpretiert.</span></span></p> +</div> + +<p><span class="tlid-translation translation" lang="de"><span title="">Wenn der Schlüssel also "dGhlIHNhbXBsZSBub25jZQ ==" war, lautet der Wert des Sec-WebSocket-Accept-Headers "s3pPLMBiTxaQ9kYGzzhZRbK + xOo =".</span> <span title="">Sobald der Server diese Header sendet, ist der Handshake abgeschlossen und Sie können mit dem Datenaustausch beginnen !</span></span></p> + +<div class="note"> +<p><span class="tlid-translation translation" lang="de"><span title=""><strong><u>Hinweis</u></strong>: Der Server kann andere Header wie {{HTTPHeader ("Set-Cookie")}} senden oder über andere Statuscodes nach Authentifizierung oder Weiterleitung fragen, bevor er den Antwort-Handshake sendet.</span></span></p> +</div> + +<h3 id="Clients_im_Auge_behalten"> <span class="tlid-translation translation" lang="de"><span title="">Clients im Auge behalten</span></span></h3> + +<p><span class="tlid-translation translation" lang="de"><span title="">Dies bezieht sich nicht direkt auf das WebSocket-Protokoll, ist jedoch hier erwähnenswert: Ihr Server muss die Sockets der Clients verfolgen, damit Sie bei Clients, die den Handshake bereits abgeschlossen haben, nicht erneut Handshakes durchführen.</span> <span title="">Dieselbe Client-IP-Adresse kann mehrmals versuchen, eine Verbindung herzustellen.</span> <span title="">Der Server kann sie jedoch ablehnen, wenn sie zu viele Verbindungen versuchen, um sich vor Denial-of-Service-Angriffen zu schützen.</span><br> + <br> + <span title="">Beispielsweise können Sie eine Tabelle mit Benutzernamen oder ID-Nummern zusammen mit den entsprechenden {{domxref ("WebSocket")}} und anderen Daten führen, die Sie dieser Verbindung zuordnen müssen.</span></span></p> + +<h2 id="Exchanging_data_frames">Exchanging data frames</h2> + +<p>Either the client or the server can choose to send a message at any time — that's the magic of WebSockets. However, extracting information from these so-called "frames" of data is a not-so-magical experience. Although all frames follow the same specific format, data going from the client to the server is masked using <a href="https://en.wikipedia.org/wiki/XOR_cipher">XOR encryption</a> (with a 32-bit key). Section 5 of the specification describes this in detail.</p> + +<h3 id="Format">Format</h3> + +<p>Each data frame (from the client to the server or vice-versa) follows this same format:</p> + +<pre class="notranslate">Frame format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-------+-+-------------+-------------------------------+ + |F|R|R|R| opcode|M| Payload len | Extended payload length | + |I|S|S|S| (4) |A| (7) | (16/64) | + |N|V|V|V| |S| | (if payload len==126/127) | + | |1|2|3| |K| | | + +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + + | Extended payload length continued, if payload len == 127 | + + - - - - - - - - - - - - - - - +-------------------------------+ + | |Masking-key, if MASK set to 1 | + +-------------------------------+-------------------------------+ + | Masking-key (continued) | Payload Data | + +-------------------------------- - - - - - - - - - - - - - - - + + : Payload Data continued ... : + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + | Payload Data continued ... | + +---------------------------------------------------------------+</pre> + +<p>The MASK bit tells whether the message is encoded. Messages from the client must be masked, so your server must expect this to be 1. (In fact, <a href="http://tools.ietf.org/html/rfc6455#section-5.1">section 5.1 of the spec</a> says that your server must disconnect from a client if that client sends an unmasked message.) When sending a frame back to the client, do not mask it and do not set the mask bit. We'll explain masking later. <em>Note: You must mask messages even when using a secure socket. </em>RSV1-3 can be ignored, they are for extensions.</p> + +<p>The opcode field defines how to interpret the payload data: <span style="font-family: courier new,andale mono,monospace; line-height: 1.5;"><code>0x0</code> </span><span style="line-height: 1.5;">for continuation,</span><span style="font-family: courier new,andale mono,monospace; line-height: 1.5;"> </span><code style="font-style: normal; line-height: 1.5;">0x1</code><span style="line-height: 1.5;"> for text (which is always encoded in UTF-8), </span><code style="font-style: normal; line-height: 1.5;">0x2</code><span style="line-height: 1.5;"> for binary, and other so-called "control codes" that will be discussed later. In this version of WebSockets, <code>0x3</code> to <code>0x7</code> and <code>0xB</code> to <code>0xF</code> have no meaning.</span></p> + +<p>The FIN bit tells whether this is the last message in a series. If it's 0, then the server keeps listening for more parts of the message; otherwise, the server should consider the message delivered. More on this later.</p> + +<h3 id="Decoding_Payload_Length">Decoding Payload Length</h3> + +<p>To read the payload data, you must know when to stop reading. That's why the payload length is important to know. Unfortunately, this is somewhat complicated. To read it, follow these steps:</p> + +<ol> + <li>Read bits 9-15 (inclusive) and interpret that as an unsigned integer. If it's 125 or less, then that's the length; you're <strong>done</strong>. If it's 126, go to step 2. If it's 127, go to step 3.</li> + <li>Read the next 16 bits and interpret those as an unsigned integer. You're <strong>done</strong>.</li> + <li>Read the next 64 bits and interpret those as an unsigned integer. (The most significant bit <em>must</em> be 0.) You're <strong>done</strong>.</li> +</ol> + +<h3 id="Reading_and_Unmasking_the_Data">Reading and Unmasking the Data</h3> + +<p>If the MASK bit was set (and it should be, for client-to-server messages), read the next 4 octets (32 bits); this is the masking key. <span style="line-height: 1.5;">Once the payload length and masking key is decoded, you can read that number of bytes from the socket. Let's call the data <strong>ENCODED</strong>, and the key <strong>MASK</strong>. To get <strong>DECODED</strong>, loop through the octets (bytes a.k.a. characters for text data) of <strong>ENCODED</strong> and XOR the octet with the (i modulo 4)th octet of MASK. In pseudo-code (that happens to be valid JavaScript):</span></p> + +<pre class="notranslate">var DECODED = ""; +for (var i = 0; i < ENCODED.length; i++) { + DECODED[i] = ENCODED[i] ^ MASK[i % 4]; +<span style="line-height: 1.5;">}</span></pre> + +<p><span style="line-height: 1.5;">Now you can figure out what <strong>DECODED</strong> means depending on your application.</span></p> + +<h3 id="Message_Fragmentation">Message Fragmentation</h3> + +<p>The FIN and opcode fields work together to send a message split up into separate frames. This is called message fragmentation. Fragmentation is only available on opcodes <code>0x0</code> to <code>0x2</code>.</p> + +<p><span style="line-height: 1.5;">Recall that the opcode tells what a frame is meant to do. If it's <code>0x1</code>, the payload is text. If it's <code>0x2</code>, the payload is binary data.</span><span style="line-height: 1.5;"> However, if it's </span><code style="font-style: normal; line-height: 1.5;">0x0,</code><span style="line-height: 1.5;"> the frame is a continuation frame; this means the server should concatenate the frame's payload to the last frame it received from that client.</span><span style="line-height: 1.5;"> Here is a rough sketch, in which a server reacts to a client sending text messages. The first message is sent in a single frame, while the second message is sent across three frames. FIN and opcode details are shown only for the client:</span></p> + +<pre style="font-size: 14px;"><strong>Client:</strong> FIN=1, opcode=0x1, msg="hello" +<strong>Server:</strong> <em>(process complete message immediately) </em>Hi. +<strong>Client:</strong> FIN=0, opcode=0x1, msg="and a" +<strong>Server:</strong> <em>(listening, new message containing text started)</em> +<strong>Client:</strong> FIN=0, opcode=0x0, msg="happy new" +<strong>Server:</strong> <em>(listening, payload concatenated to previous message)</em> +<strong>Client:</strong> FIN=1, opcode=0x0, msg="year!" +<strong>Server:</strong> <em>(process complete message) </em>Happy new year to you too!</pre> + +<p>Notice the first frame contains an entire message (has <code>FIN=1</code> and <code>opcode!=0x0</code>), so the server can process or respond as it sees fit. The second frame sent by the client has a text payload (<code>opcode=0x1</code>), but the entire message has not arrived yet (<code>FIN=0</code>). All remaining parts of that message are sent with continuation frames (<code>opcode=0x0</code>), and the final frame of the message is marked by <code>FIN=1</code>. <a href="http://tools.ietf.org/html/rfc6455#section-5.4">Section 5.4 of the spec</a> describes message fragmentation.</p> + +<h2 id="Pings_and_Pongs_The_Heartbeat_of_WebSockets">Pings and Pongs: The Heartbeat of WebSockets</h2> + +<p>At any point after the handshake, either the client or the server can choose to send a ping to the other party. When the ping is received, the recipient must send back a pong as soon as possible. You can use this to make sure that the client is still connected, for example.</p> + +<p>A ping or pong is just a regular frame, but it's a <strong>control frame</strong>. Pings have an opcode of <code>0x9</code>, and pongs have an opcode of <code>0xA</code>. When you get a ping, send back a pong with the exact same Payload Data as the ping (for pings and pongs, the max payload length is 125). You might also get a pong without ever sending a ping; ignore this if it happens.</p> + +<div class="note"> +<p>If you have gotten more than one ping before you get the chance to send a pong, you only send one pong.</p> +</div> + +<h2 id="Closing_the_connection">Closing the connection</h2> + +<p>To close a connection either the client or server can send a control frame with data containing a specified control sequence to begin the closing handshake (detailed in <a href="http://tools.ietf.org/html/rfc6455#section-5.5.1">Section 5.5.1</a>). Upon receiving such a frame, the other peer sends a Close frame in response. The first peer then closes the connection. Any further data received after closing of connection is then discarded. </p> + +<h2 id="Miscellaneous_2"><a name="Miscellaneous">Miscellaneous</a></h2> + +<div class="note"> +<p>WebSocket codes, extensions, subprotocols, etc. are registered at the <a href="http://www.iana.org/assignments/websocket/websocket.xml">IANA WebSocket Protocol Registry</a>.</p> +</div> + +<p>WebSocket extensions and subprotocols are negotiated via headers during <a href="#Handshake">the handshake</a>. Sometimes extensions and subprotocols very similar, but there is a clear distinction. Extensions control the WebSocket <em>frame</em> and <em>modify</em> the payload, while subprotocols structure the WebSocket <em>payload</em> and <em>never modify</em> anything. Extensions are optional and generalized (like compression); subprotocols are mandatory and localized (like ones for chat and for MMORPG games).</p> + +<h3 id="Extensions">Extensions</h3> + +<div class="note"> +<p><strong>This section needs expansion. Please edit if you are equipped to do so.</strong></p> +</div> + +<p>Think of an extension as compressing a file before e-mailing it to someone. Whatever you do, you're sending the <em>same</em> data in different forms. The recipient will eventually be able to get the same data as your local copy, but it is sent differently. That's what an extension does. WebSockets defines a protocol and a simple way to send data, but an extension such as compression could allow sending the same data but in a shorter format.</p> + +<div class="note"> +<p>Extensions are explained in sections 5.8, 9, 11.3.2, and 11.4 of the spec.</p> +</div> + +<p><em>TODO</em></p> + +<h3 id="Subprotocols">Subprotocols</h3> + +<p>Think of a subprotocol as a custom <a href="https://en.wikipedia.org/wiki/XML_schema">XML schema</a> or <a href="https://en.wikipedia.org/wiki/Document_Type_Definition">doctype declaration</a>. You're still using XML and its syntax, but you're additionally restricted by a structure you agreed on. WebSocket subprotocols are just like that. They do not introduce anything fancy, they just establish structure. Like a doctype or schema, both parties must agree on the subprotocol; unlike a doctype or schema, the subprotocol is implemented on the server and cannot be externally refered to by the client.</p> + +<div class="note"> +<p>Subprotocols are explained in sections 1.9, 4.2, 11.3.4, and 11.5 of the spec.</p> +</div> + +<p>A client has to ask for a specific subprotocol. To do so, it will send something like this <em>as part of the original handshake</em>:</p> + +<pre class="notranslate">GET /chat HTTP/1.1 +... +Sec-WebSocket-Protocol: soap, wamp + +</pre> + +<p>or, equivalently:</p> + +<pre class="notranslate">... +Sec-WebSocket-Protocol: soap +Sec-WebSocket-Protocol: wamp + +</pre> + +<p>Now the server must pick one of the protocols that the client suggested and it supports. If there is more than one, send the first one the client sent. Imagine our server can use both <code>soap</code> and <code>wamp</code>. Then, in the response handshake, it sends:</p> + +<pre class="notranslate">Sec-WebSocket-Protocol: soap + +</pre> + +<div class="warning"> +<p>The server can't send more than one <code>Sec-Websocket-Protocol</code> header.<br> + <span style="line-height: 1.5;">If the server doesn't want to use a</span><span style="line-height: 1.5;">ny subprotocol, </span><em><strong style="line-height: 1.5;">it shouldn't send any <code>Sec-WebSocket-Protocol</code> header</strong></em><span style="line-height: 1.5;">. Sending a blank header is incorrect. The client may close the connection if it doesn't get the subprotocol it wants.</span></p> +</div> + +<p>If you want your server to obey certain subprotocols, then naturally you'll need extra code on the server. Let's imagine we're using a subprotocol <code>json</code>. In this subprotocol, all data is passed as <a href="https://en.wikipedia.org/wiki/JSON">JSON</a>. If the client solicits this protocol and the server wants to use it, the server needs to have a JSON parser. Practically speaking, this will be part of a library, but the server needs to pass the data around.</p> + +<div class="note"> +<p><strong>Tip:</strong> To avoid name conflict, it's recommended to make your subprotocol name part of a domain string. If you are building a custom chat app that uses a proprietary format exclusive to Example Inc., then you might use this: <code>Sec-WebSocket-Protocol: chat.example.com</code>. Note that this isn't required, it's just an optional convention, and you can use any string you wish.</p> +</div> + +<h2 id="Related">Related</h2> + +<ul> + <li><a href="https://github.com/alexhultman/libwshandshake">WebSocket handshake library in C++</a></li> + <li><a href="/en-US/docs/WebSockets/Writing_WebSocket_client_applications">Writing WebSocket client applications</a></li> + <li><a href="/en-US/docs/WebSockets/Writing_WebSocket_server" title="/en-US/docs/WebSockets/Writing_WebSocket_server">Tutorial: Websocket server in C#</a></li> + <li><a href="/en-US/docs/WebSockets/WebSocket_Server_Vb.NET">Tutorial: Websocket server in VB.NET</a></li> + <li><a href="/en-US/docs/Web/API/WebSockets_API/Writing_a_WebSocket_server_in_Java">Tutorial: Websocket server in Java</a></li> +</ul> |