Volg doorverwijzingen met een hoplimiet

Je server beantwoordt GET /v0/books/2?x=1 nu met 308 Permanent Redirect en location: /books/2?x=1, en http.client geeft dat antwoord terug en stopt. Niets in HTTP stuurt het tweede verzoek voor je. Of je volgt, waar je precies heen gaat, welke methode en body je daar stuurt, en wanneer je opgeeft, zijn allemaal beslissingen van de client. Deze les schrijft een client die ze neemt: follow, in wire.py, opgebouwd uit drie kleine functies.

Eén verzoek

request_once(method, url, *, body, headers, make_connection, timeout) stuurt één verzoek en geeft één record terug. Je hebt hem al eens geschreven: het is get_json uit hoofdstuk 3, les 1, met elke methode, elke URL en een optionele body in plaats van een GET naar practice-api.

• url_parts(url) uit les 2 geeft de host, de poort en het target.

• with contextlib.closing(make_connection(host, port, timeout=timeout)) as conn: maakt het verbindingsobject en sluit het op elk pad, ook als getresponse() een TimeoutError opwerpt.

• conn.request(method, target, body=body, headers=headers) stuurt het verzoek. body is None voor een verzoek zonder body.

• Bouw binnen het blok de header-dict uit response.getheaders() met namen in kleine letters en lijsten waarden, precies zoals get_json doet, en lees de body.

Het record heeft "status", "reason", "headers", "body", en één nieuwe sleutel, "url": de URL waar dit verzoek naartoe ging. Een volger heeft die nodig, omdat na een doorverwijzing de URL die antwoordde niet meer de URL is waarmee hij begon.

De methode na een doorverwijzing

Les 1 deelde de vijf doorverwijsstatussen in naar wat ze met de methode doen. next_method(status, method) maakt van die tabel code en geeft de methode voor het volgende verzoek terug:

Als de methode verandert, gaat de body ook weg: een GET draagt er geen. Hetzelfde geldt voor de header content-type van het verzoek, die een body beschreef die niet meer wordt verstuurd. Als de methode blijft, gaan de body en elke header ongewijzigd naar het nieuwe adres. Dat is precies waar 307 en 308 voor bestaan.

Stoppen

Een server kan een client in een cirkel sturen: /a verwijst door naar /b, en /b terug naar /a. Een volger die elke location vertrouwt, stuurt verzoeken tot er iets breekt. Daarom telt follow. Hij krijgt max_hops, het maximale aantal doorverwijzingen dat hij volgt, standaard 5 (MAX_HOPS). Een hop is één gevolgde doorverwijzing. Als er al max_hops doorverwijzingen zijn gevolgd en het antwoord is weer een doorverwijzing, werpt follow ValueError op in plaats van nog een verzoek te sturen. Met max_hops=3 tegen de cirkel stuurt hij vier verzoeken en werpt hij na het vierde een exception op:

moves = {"/a": "/b", "/b": "/a"}
path = "/a"
requests = 1
while path in moves and requests < 4:
    path = moves[path]
    requests = requests + 1
print(path, requests)

Alleen een antwoord dat een doorverwijzing is, telt. REDIRECTS, bovenaan wire.py, somt de vijf statussen op die follow volgt. Een antwoord met een andere status is definitief, en een 3xx zonder header location ook, want die geeft de client geen plek om heen te gaan. 304 Not Modified is ook een 3xx, maar staat niet in de lijst: het is een antwoord, geen verwijzing.

De sleutel history

follow geeft het laatste record terug met nog één sleutel, "history": een lijst met één dict per gevolgde doorverwijzing, elk met de "status" van de doorverwijzing en de "url" die hem stuurde. Een lege lijst betekent dat er geen doorverwijzing was. requests bewaart dezelfde informatie, als een lijst van de doorverwijsantwoorden, in response.history, wat hoofdstuk 10 laat zien.

Hier is de lus die alles samenbrengt:

1. Stuur het verzoek met request_once.

2. Als de status niet in REDIRECTS staat, of er geen location is, stop dan: dit record is het antwoord.

3. Als len(history) al gelijk is aan max_hops, werp je ValueError op.

4. Voeg {"status": ..., "url": ...} voor dit antwoord toe aan history.

5. Bepaal de methode met next_method. Als die veranderd is, zet je de body op None en laat je de content-type van het verzoek weg uit de headers.

6. Los de location op ten opzichte van de huidige URL met resolve_location, maak dat de huidige URL, en ga terug naar stap 1.

Een while True:-lus die bij stap 2 met break eindigt, past bij deze vorm. Oplossen ten opzichte van de huidige URL, niet de eerste, is wat de derde URL in de quiz van les 2 /books/3 maakte.

Echte clients doen nog één ding: ze laten inloggegevens zoals een header Authorization vallen, zodat een login die voor de ene server bedoeld is, nooit aan een andere wordt gegeven. RFC 9110 (sectie 15.4) vraagt meer dan bibliotheken meestal doen: het vraagt een client om Authorization en Cookie bij elke automatische doorverwijzing te laten vallen, terwijl bibliotheken zoals requests ze alleen laten vallen als de host verandert. Hoofdstuk 7 komt hierop terug.

Jouw opdracht

Schrijf in wire.py next_method, request_once en follow. follow maakt van headers=None een {} vóór het eerste verzoek, sluit elke verbinding via request_once, en geeft timeout aan elke verbinding mee. Voer daarna het hulpprogramma uit:

python pl_http.py follow

Het roept wire.follow("GET", "http://books.test/v0/books/2", make_connection=...) aan, waarbij de verbinding die het meegeeft naar je eigen server op deze machine gaat, dus books.test wordt nooit opgezocht. Elk verzoek en het record dat je follow teruggaf, worden afgedrukt:

request 1  GET /v0/books/2  ->  308 Permanent Redirect
request 2  GET /books/2  ->  200 OK
--- your client returned ---
status: 200
...
url: 'http://books.test/books/2'
history: [{'status': 308, 'url': 'http://books.test/v0/books/2'}]

De weggelaten regels zijn de reason, de headers en de body van boek 2.

Klik daarna op Check my work. Je client en je server zijn het nu eens over één doorverwijzing. De volgende les geeft dezelfde taak aan een bibliotheek en vergelijkt de regels daarvan met de jouwe.