URLs gestalten und Prozentkodierungsregeln anwenden

Ziel

URLs, die über Jahre gültig bleiben, beim Vergleich als gleich gelten, wenn sie dieselbe Ressource bezeichnen, und Logs, die Encoder anderer Systeme sowie Kopieren-und-Einfügen durchlaufen, ohne doppelt kodiert zu werden oder ungewollte Struktur zu erzeugen.

Voraussetzungen

RFC 3986: Ein URI besteht aus Scheme, Authority, Path, Query und Fragment; reservierte Zeichen sind die Gen-Delims :/?#[]@ und Sub-Delims !$&'()*+,;=; unreserviert sind Buchstaben, Ziffern, -, ., _ und ~. Der WHATWG-URL-Standard ist das, was Browser und viele Bibliotheken implementieren; er definiert komponentenspezifische Percent-Encode-Sets und das von HTML-Formularen verwendete Format application/x-www-form-urlencoded.

Schritte

1. Struktur wählen: Substantive für Sammlungen und Einzelobjekte (/orders/123), kleingeschriebene, mit Bindestrichen verbundene Wörter, eine einheitliche Regel für abschliessende Schrägstriche, keine Dateiendungen ausser zur Formatauswahl, und nie Session-IDs oder Tokens in einer URL, da URLs in Logs und Referer-Headern landen.
2. Identität und Hierarchie in den Pfad legen, Filterung, Seitenwechsel und Optionen in die Query; Query-Parameter mit dokumentierten Standardwerten reihenfolgeunabhängig gestalten.
3. URLs komponentenweise mit einer Bibliothek aufbauen: jedes Pfadsegment sowie jeden Query-Schlüssel und -Wert einzeln kodieren, dann zusammenfügen. Nie einen Encoder über eine fertige URL laufen lassen.
4. Die UTF-8-Oktette eines Werts kodieren. In einem Pfadsegment /, ?, #, % und Nicht-ASCII kodieren; in einem Query-Wert zusätzlich &, = und +. Unreservierte Zeichen unverändert lassen und Hexadezimalziffern grossschreiben, wie RFC 3986 es von Erzeugern verlangt.
5. + bewusst behandeln: In formularkodierten Query-Strings wird aus einem Leerzeichen ein +, und ein tatsächliches Pluszeichen wird zu %2B; in Pfaden ist + nur ein Zeichen. Für die Query einen Formular-Decoder verwenden und für den Pfad einen reinen Prozent-Decoder, sowohl auf Client- als auch auf Serverseite.
6. Genau einmal dekodieren, nach dem Aufteilen in Komponenten, an der Grenze des eigenen Systems. RFC 3986 hält fest, dass Implementierungen dieselbe Zeichenkette nicht mehrfach prozentkodieren oder -dekodieren dürfen; frühes Dekodieren macht aus %2F einen Pfadtrenner.
7. Für den Vergleich normalisieren: Scheme und Host kleinschreiben, prozentkodierte Hexziffern grossschreiben, prozentkodierte unreservierte Zeichen dekodieren, Punktsegmente und den Standardport entfernen. Den Pfad nicht kleinschreiben, ausser der eigene Server behandelt Pfade ohne Berücksichtigung der Gross-/Kleinschreibung.
8. Eine kanonische Form veröffentlichen und Varianten (Gross-/Kleinschreibung, abschliessender Schrägstrich, index.html) mit einer dauerhaften Weiterleitung dorthin umleiten.
9. Testen, indem schwierige Werte (Leerzeichen, /, ?, %, +, ä, ein Emoji, ..) im Round-Trip durch jeden Client-Encoder und den Server-Decoder geschickt und die zurückgewonnenen Segmente verglichen werden.

Erwartetes Ergebnis

Eine kanonische URL pro Ressource; Encoder in verschiedenen Sprachen erzeugen für dieselben Komponenten byteidentische URLs; Dekodieren macht aus Daten nie Struktur.

Grenzen und Prüfbasis

RFC 3986 und der WHATWG-Parser unterscheiden sich in Details (Letzterer ist bei der Eingabe nachsichtiger), sodass das Verhalten einer Bibliothek geprüft und nicht einfach angenommen werden muss. Entnommen aus den zitierten Spezifikationen; es werden keine Messungen behauptet.