Thema: http
-
HTTP-Statuscodes richtig verwenden: die erste Verzweigung des Clients
Clients, Caches und Agenten entscheiden allein am Statuscode über Wiederholen, Neuladen oder Aufgeben: 201/204 für Erfolg mit und ohne Körper, 401 gegen 403 für fehlende Anmeldung gegen fehlende Berechtigung, 409/412/428 für Konflikte und Vorbedingungen, 429 und 503 mit Retry-After für «später». Ein 200 mit Fehlerobjekt täuscht alle.
-
Retry-After als Untergrenze respektieren
Wiederholungsversuche anhand der jeweils vorliegenden Form von Retry-After planen, dabei die Aufgabenfrist einhalten und verfrühte wiederholte Anfragen vermeiden.
-
Als Client zurückweichen: Retry-After, RateLimit-Header und Budgets pro Host
Wie ein Agent auf 429- und 503-Antworten sowie auf informative Rate-Limit-Header reagieren sollte: Retry-After exakt befolgen, sonst exponentiell mit Jitter zurückweichen, die Felder RateLimit und RateLimit-Policy lesen, sofern ein Server sie sendet, um dem Limit zuvorzukommen, ein Budget pro Host und pro Schlüssel führen und einen nicht-idempotenten Schreibvorgang nie ohne Idempotenzschlüssel wiederholen.
-
Antwortkomprimierung: wo sie erfolgen sollte und was auszunehmen ist
Textantworten (HTML, JSON, Markdown) am Proxy oder in der Anwendung komprimieren, bereits komprimierte und gestreamte Inhalte auslassen, ETags über Kodierungen hinweg ehrlich halten und Vary: Accept-Encoding setzen.
-
Verteiltes Tracing in Umrissen: Spans, Eltern-Kennungen und W3C Trace Context
Ein Trace ist ein Baum aus Spans, jeder mit Trace-Kennung, eigener Span-Kennung, Eltern-Span-Kennung, Zeitstempeln, Attributen und Status; der W3C-Header traceparent trägt Trace-Kennung, Eltern-Kennung und ein Sampled-Flag über Prozessgrenzen, und ein Dienst, der beide Header nur weiterreicht, hält Traces trotzdem zusammen.
-
Individuelle 404-Seiten und Soft 404s: die Fehlerseite mit dem Fehlerstatus ausliefern
Eine individuelle 404-Seite hilft Nutzenden nur, wenn sie mit Status 404 ausgeliefert wird; eine Nicht-gefunden-Seite mit Status 200 ist ein Soft 404, den Crawler weiter abrufen und den Suchmaschinen ausschliessen. nginx' error_page kann den Status umschreiben (error_page 404 =200 ...), und genau so entstehen Soft 404s versehentlich; den Status beibehalten, die Seite nützlich gestalten und mit curl -I prüfen.
-
Die Same-Origin Policy: was eine Origin ist und was sie isoliert
Eine Origin besteht aus Schema, Host und Port einer URL. Skripte dürfen Dokumente, Speicher und Antworten derselben Origin lesen und ändern; ursprungsübergreifende Lesezugriffe sind standardmässig blockiert, während ursprungsübergreifende Schreibzugriffe wie Formularübermittlungen sowie Einbettungen wie Bilder und Skripte grundsätzlich erlaubt sind. CORS lockert Lesezugriffe; CSRF-Schutzmassnahmen bleiben trotzdem nötig.
-
fetch mit Timeouts und AbortController einsetzen
Ein fetch-Promise wird nur bei einem Netzwerkfehler abgelehnt, nicht bei einem HTTP-Fehlerstatus, und besitzt von sich aus kein Timeout. Ein AbortSignal übergeben, das aus AbortSignal.timeout und dem Controller einer aufrufenden Stelle kombiniert ist, response.ok prüfen und im catch-Block TimeoutError, AbortError, Netzwerkfehler und HTTP-Fehler auseinanderhalten.
-
Idempotente Operationen und sichere Wiederholungen entwerfen
Eine Operation ist idempotent, wenn ihre mehrfache Ausführung dieselbe Wirkung hat wie eine einzelne; RFC 9110 legt das für HTTP-Methoden fest, und ein Idempotency-Key-Header überträgt die Eigenschaft auf POST. Schlüssel samt Fingerabdruck und Ergebnis speichern, Konflikte mit 409 und 422 melden, Schlüssel nach dokumentierter Frist löschen.
-
Server-Sent Events im Vergleich zu WebSockets
Server-Sent Events streamen Textereignisse vom Server zum Client über gewöhnliches HTTP mit automatischer Wiederverbindung und Last-Event-IDs; WebSockets bieten einen bidirektionalen, binärfähigen Kanal mit eigenem Protokoll. SSE für einseitige Aktualisierungen wählen, WebSockets, wenn der Client häufig senden muss.
-
Die TypeSafe-API aus einem Agenten heraus aufrufen: Aufbau der Anfrage, Fehler, erneute Versuche und Versionsfixierung
Der dokumentierte Vertrag, den ein Agent braucht, um Jev ohne Chat-Schicht aufzurufen: POST /v1/systemone mit einem Bearer-Schlüssel, einem Zustand, einem Modellnamen und einer Zuordnung typisierter Fragen; Antworten unter denselben Schlüsseln wie die Fragen plus einem usage-Block; 401, 422, 429 und 529 mit exponentiellem Backoff; Aliasse, die sich verschieben, und versionierte Kennungen, die es nicht tun; SDK-Standardwerte für erneute Versuche und der Agenten-Skill für Coding-Agenten.
-
Der Link-Header und Link-Relationstypen
RFC 8288 erlaubt jeder HTTP-Antwort, getypte Links in einem Link-Header zu tragen: <ziel>; rel="relation" plus optionale Parameter anchor, hreflang, type, title und media. Relationsnamen stammen aus der IANA-Registry (next, prev, canonical, alternate, describedby, preload) oder sind absolute URIs für private Erweiterungen. So verweisen Nicht-HTML-Antworten auf ihre Nachbarn, und so teilt 103 Early Hints einem Browser mit, was früh abzurufen ist.
-
Web-Push-Grundlagen: Subscriptions, VAPID-Schlüssel und der Push-Dienst
Ein Browser abonniert beim Push-Dienst seines Herstellers und übergibt der Seite einen Endpoint plus Schlüssel; der Anwendungsserver sendet verschlüsselte Nachrichten per POST an diesen Endpoint mit einem TTL-Header und einem VAPID-JWT (ES256, aud = Ursprung des Push-Dienstes, exp höchstens 24 Stunden), dessen öffentlicher Schlüssel als applicationServerKey an PushManager.subscribe übergeben wurde. Ein 201 bedeutet angenommen, nicht zugestellt.
-
Sitemaps und kanonische Adressen: ein Inhalt, eine Adresse
Jeder Inhalt sollte genau eine kanonische HTTPS-Adresse haben, die auf der Seite selbst erklärt wird; Zwillinge wie Markdown- oder JSON-Fassungen verweisen per Link-Header darauf, Parameter ohne Inhaltswirkung erzeugen keine neuen Adressen, und die Sitemap listet nur kanonische Adressen mit wahren Änderungsdaten.
-
HEAD und OPTIONS: was sie beantworten und wofür Clients sie nutzen
HEAD ist GET ohne Rumpf: gleicher Status und gleiche Header (Content-Length und Vary dürfen fehlen), cachefähig, eingesetzt für Link-Prüfungen, Grössenabfragen und Aktualitätsprüfungen. OPTIONS fragt, welche Kommunikationsoptionen eine Ressource oder der gesamte Server (OPTIONS *) unterstützt, wird typischerweise mit Allow beantwortet, ist nicht cachefähig und trägt CORS-Preflights mit Access-Control-Request-Method.
-
URL-Shortener im Durchgang: Schlüsselerzeugung, Weiterleitungsstatus und Missbrauchskontrollen
Ein Entwurfsdurchgang für einen URL-Shortener: zufällige Base62-Schlüssel mit Kollisionswiederholung, ein Weiterleitungspfad, der genau einen Cache und einen Speicher berührt, 302 statt 301, wenn Ziele widerrufbar und zählbar bleiben müssen, Missbrauchsprüfungen bei der Erstellung, und eine Liste dessen, was zuerst nicht gebaut werden sollte.
-
Weiterleitungsketten auf einen einzigen Sprung zu verkürzen erhöht auf einer grossen Website den Anteil der Crawler-Anfragen, die mit 200 enden
Hypothese: Auf einer Website mit Zehntausenden URLs und angesammelten Weiterleitungen erhöht das Umschreiben jeder Kette, sodass jede alte URL mit genau einer Weiterleitung auf ihr endgültiges Ziel antwortet, bei einem festen täglichen Anfragevolumen messbar den Anteil der Suchcrawler-Anfragen, die eine 200-Seite erreichen, weil Crawler Anfragen für jeden Sprung aufwenden; ein vorgeschlagener Vorher-Nachher-Test anhand von Server-Logs.
-
JSON Web Tokens: Was schiefgehen kann und die Antworten von RFC 8725
JWTs sind signierte Claims, keine verschlüsselten Geheimnisse; den Algorithmus gegen eine Positivliste prüfen, Aussteller, Zielgruppe und Ablauf verifizieren, Lebensdauern kurz halten, 'none' nie akzeptieren, und daran denken, dass sich ein zustandsloses Token ohne serverseitige Liste nicht widerrufen lässt.
-
Bulk-Endpunkte und die Meldung teilweiser Fehlschläge
Ein Bulk-Endpunkt gelingt oder scheitert entweder als Ganzes, oder er meldet die Ergebnisse pro Element; ein einzelnes 200 kann einen Teilerfolg nicht ausdrücken, daher pro Endpunkt ein Verhalten festlegen, Fehlschläge nach Position indexieren, die Batchgrösse begrenzen und Autorisierung sowie Ratenbegrenzung pro Element anwenden.
-
HTTP-Statuscodes bewusst wählen
Statuscodes sind das Erste, wonach ein Client verzweigt: 200/201/204 für Erfolg, 304 für unverändert, 400/422 für fehlerhafte Eingaben, 401/403 für Anmeldedaten gegenüber Berechtigung, 404 für nicht vorhanden, 409/412/428 für Konflikte und Vorbedingungen, 429/503 für später.
Maschinenlesbar: JSON