Die Hälfte des Clients schreiben

Dein Server kann eine Anfrage zerlegen, entscheiden und antworten. Noch sendet ihm niemand eine Anfrage. Diese Lektion schreibt die andere Seite: den Client, der einen Schlüssel erzeugt, die Upgrade-Anfrage schreibt und die Antwort des Servers prüft, bevor er glaubt, dass das Protokoll gewechselt hat.

Ein neuer Schlüssel

Der Schlüssel des Clients besteht aus 16 zufälligen Bytes in base64, neu für jede Anfrage. Pythons os.urandom(16) gibt 16 Bytes aus der Quelle unvorhersehbarer Zufälligkeit des Betriebssystems zurück, und das ist die richtige Quelle für Werte, die ein anderes Programm nicht erraten können darf. base64.b64encode macht daraus die 24 Zeichen eines Schlüssels, und .decode("ascii") macht daraus Text.

Ein Test kann einen zufälligen Schlüssel nicht prüfen, weil er ihn nicht im Voraus kennen kann. Deshalb nimmt make_client_key die Quelle der Zufälligkeit als Parameter, mit der echten als Standardwert:

def make_client_key(random_bytes=os.urandom):
    ...

Rufe darin random_bytes(16) auf. Im normalen Gebrauch ruft das os.urandom(16) auf. Ein Test übergibt stattdessen eine andere Funktion, eine, die bekannte Bytes zurückgibt, und weiß dann genau, welcher Schlüssel herauskommt. Das ist dieselbe Idee wie der Parameter connect=, den du in Networks with Python kennengelernt hast: eine Funktion, die als Wert übergeben wird, damit ein Test seine eigene einsetzen kann.

import base64


def fixed(n):
    return bytes(range(n))


key = base64.b64encode(fixed(16)).decode("ascii")

Mit dieser Funktion ist der Schlüssel bei jedem Lauf derselbe: das base64 der Bytes 0 bis 15. Ein Test ruft make_client_key(random_bytes=fixed) auf. Er übergibt fixed, die Funktion selbst, ohne Klammern, und make_client_key entscheidet, wann sie aufgerufen wird und womit.

Die Anfrage

build_upgrade_request(host, path, key) schreibt die Anfrage, die du in Lektion 1 gelesen hast, ohne die beiden optionalen Zeilen:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Das ist die Anfrage für Host, Pfad und Schlüssel des RFC; deine Funktion setzt ihre eigenen drei Argumente an deren Stelle. host ist Text wie server.example.com oder ein Name mit Port wie 127.0.0.1:50123, wenn der Server nicht auf dem Standardport läuft, und er kommt unverändert in die Host-Zeile. path kommt unverändert in die Anfragezeile, samt Query. Jede Zeile endet mit \r\n, eine Leerzeile beendet den Kopf, und die Anfrage hat keinen Body. Dein Client sendet keine Origin-Zeile, weil er kein Browser ist, und keine Sec-WebSocket-Protocol-Zeile, weil er nach keinem Subprotokoll fragt. Gib die Anfrage mit "ascii" kodiert zurück.

Die Antwort prüfen

Der Server antwortet mit einem Kopf, den read_head ohne sein abschließendes \r\n\r\n zurückgibt. check_accept_response(data, key) entscheidet, ob dieser Kopf Ja bedeutet. Sie gibt nichts zurück, wenn das so ist, und löst ValueError mit einer Meldung aus, die den Grund nennt, wenn nicht.

Beginne mit der Statuszeile, geschnitten mit split(" ", 2) wie in HTTP with Python, Lektion 1.4. Eine Zeile wie HTTP/1.1 allein hat überhaupt keinen Code; prüfe, wie viele Teile du bekommen hast, bevor du den zweiten liest, und löse ValueError aus, wenn der Code fehlt.

Jeder andere Status als 101 bedeutet für diesen Client, dass der Handshake gescheitert ist. RFC 6455 sagt, dass ein Client jeden anderen Status “per HTTP procedures” behandelt, also nach den Verfahren von HTTP: Eine 401 könnte zu einer Anmeldung führen, eine 3xx zu einer Weiterleitung. Dein Client folgt keinen Weiterleitungen und sendet keine Zugangsdaten, also ist für ihn jeder andere Status, eine 426 oder eine 200 oder eine 100 Continue, ein gescheiterter Handshake. Vergleiche den Code genau mit "101"; ein anderer 1xx-Status ist keine Umstellung.

Die Wörter nach dem Code, die Reason-Phrase, sind für Menschen. Ein Server darf 101 Web Socket Protocol Handshake statt 101 Switching Protocols schreiben, und der Handshake ist genauso gut. Entscheide anhand des Codes und der Header, nie anhand der Reason-Phrase.

Lies bei einer 101 die Header mit deinem parse_headers und prüfe drei davon, die Gegenseite dessen, was du in Lektion 4 geprüft hast:

1. upgrade hat das Token websocket, per has_token, also besteht WebSocket und websockets nicht;

2. connection hat das Token upgrade, per has_token;

3. sec-websocket-accept ist genau gleich accept_value(key) für den Schlüssel, den dieser Client gesendet hat.

Der letzte Vergleich beachtet absichtlich Groß- und Kleinschreibung. In base64 sind a und A verschiedene Zeichen, die für verschiedene Bits stehen, also ist ein Accept-Wert, der sich nur in der Schreibung unterscheidet, ein anderer Wert, und er bedeutet, dass der Server die Antwort auf diesen Schlüssel nicht berechnet hat.

Deine Aufgabe

Schreibe in ws_handshake.py diese drei Funktionen, in dieser Reihenfolge:

1. make_client_key(random_bytes=os.urandom): Rufe random_bytes(16) einmal auf und gib das base64 des Ergebnisses als str zurück.

2. build_upgrade_request(host, path, key): die Anfrage von oben, als Bytes.

3. check_accept_response(data, key): Löse ValueError aus, außer wenn data ein 101-Kopf mit den beiden Tokens und dem richtigen Accept-Wert ist.

Lass serve_handshake und client_handshake für Lektion 6. Klicke auf Run. Der Abschnitt zu Lektion 5 gibt die Anfrage für Host, Pfad und Schlüssel des RFC als Bytes aus:

Lesson 5: build_upgrade_request
b'GET /chat HTTP/1.1\r\nHost: server.example.com\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nSec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==\r\nSec-WebSocket-Version: 13\r\n\r\n'

Diese Zeile stammt aus einem lokalen Lauf der fertigen Lektion. Wenn deine übereinstimmt, klicke auf Submit.

Du hast jetzt beide Hälften des Handshakes, jede für sich geprüft. Im Projekt, das dieses Kapitel abschließt, treffen sie sich über eine echte Verbindung.