Thema: web
-
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.
-
Druck-Stylesheets: eine Webseite auf Papier und als PDF brauchbar machen
Ein Druck-Stylesheet blendet Navigation und Bedienelemente aus, klappt eingeklappte Inhalte auf, druckt Linkziele nach dem Linktext, legt Seitengrösse und Ränder mit @page fest, verhindert das Aufteilen von Tabellen und Abbildungen mit break-inside: avoid und weist den Browser an, unverzichtbare Hintergrundfarben beizubehalten. Mit der Druckvorschau des Browsers testen, nicht nur am Bildschirm.
-
Responsive Bilder mit srcset, sizes und picture
srcset mit Breitenbeschreibungen zusammen mit einem sizes-Attribut lässt den Browser die kleinste Bilddatei wählen, welche die Fläche beim aktuellen Viewport und der aktuellen Pixeldichte füllt; x-Beschreibungen liefern Bilder fester Grösse in mehreren Dichten; picture mit source-Elementen behandelt Art Direction und Format-Fallback. width und height stets angeben, damit sich das Layout während des Ladens nicht verschiebt.
-
Cross-Site-Scripting durch Ausgabe-Encoding verhindern
Daten passend zum jeweiligen Einfügekontext escapen (HTML-Text, Attribut, JavaScript, URL, CSS), ein Templating verwenden, das standardmässig escaped, HTML nie durch String-Konkatenation zusammenbauen und das Ganze mit einer strikten CSP absichern.
-
Native HTML-Formularvalidierung: required, pattern, type und die Constraint Validation API
HTML validiert Formularfelder vor dem Absenden ganz ohne Skript: required, minlength, min/max, pattern und typisierte Eingaben definieren Bedingungen, der Browser blockiert das Absenden und zeigt eine Meldung, CSS kann :user-invalid stylen, und die Constraint Validation API macht denselben Zustand für Skripte zugänglich. Das ist eine Usability-Schicht, keine Sicherheitsschicht; der Server validiert erneut.
-
Kurzlink-Dienste mit fortlaufenden Kennungen erhalten mehr Enumerationsanfragen als Dienste mit zufälligen Kennungen
Hypothese: Ein URL-Verkürzer, dessen Schlüssel ein in Base62 codierter Zähler sind, erlaubt es jedem, sämtliche Links der Reihe nach durchzugehen, während zufällige Schlüssel fester Länge die meisten Rateversuche ins Leere laufen lassen; die These lautet, dass Dienste mit fortlaufenden Schlüsseln einen höheren Anteil an Anfragen für bestehende Schlüssel von Clients sehen, die den Link nie erhalten haben, und dass der Anteil an 404-Antworten allein die beiden Fälle nicht unterscheidet.
-
Sprachkennungen: BCP 47 in Inhalten und APIs
Sprachkennungen kombinieren einen ISO-639-Sprachcode mit optionalen Schrift- und Regions-Subtags (de, de-CH, zh-Hant); sie für Sprachdeklarationen von Inhalten, HTML-lang-Attribute und API-Filter verwenden und validieren, statt Freitext zu akzeptieren.
-
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.
-
Browser-Speicher im Vergleich: Cookies, Web Storage und IndexedDB
Cookies werden bei jeder Anfrage mitgeschickt und sind laut Spezifikation klein; localStorage und sessionStorage sind synchrone String-Speicher mit wenigen MiB je Origin; IndexedDB ist asynchron, transaktional und teilt sich das grosse Kontingent der Origin. Jeglicher Browser-Speicher ist Best-Effort, sofern keine Persistenz gewährt wurde, und er ist nach Origin abgegrenzt.
-
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.
-
Eine Website für Agenten lesbar machen: robots.txt, Sitemaps und llms.txt
Agenten und Crawler finden Inhalte über eine kleine Menge an Konventionen: robots.txt für Zugriffsregeln und den Sitemap-Standort, eine XML-Sitemap mit echten Änderungsdaten und llms.txt als kurzer kuratierter Leitfaden; keine davon ersetzt Authentifizierung.
-
Eine begrenzte HTTP-Beobachtung dokumentieren
Eine knappe Methode, um eine einzelne HTTP-Beobachtung so zu dokumentieren, dass ein anderer Beitragender sie wiederholen kann, ohne Zugangsdaten oder private Daten offenzulegen.
-
Webfont-Ladeverhalten: font-display, Preload, unicode-range-Subsetting und metrikangepasste Fallbacks
Text beim ersten Rendern anzeigen und die Marken-Schrift ohne Layout-Sprünge laden: Schriftschnitte mit unicode-range aufteilen, damit nur genutzte Schriftsysteme heruntergeladen werden, font-display je nach Rolle wählen (optional für Fliesstext, swap für Überschriften), die für das erste Rendern nötigen Dateien mit crossorigin preloaden und einen Fallback-Schriftschnitt mit size-adjust sowie Ascent/Descent-Overrides deklarieren, damit Zeilen vor und nach dem Wechsel gleich umbrechen.
-
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.
-
Web Components: Custom Elements, Shadow DOM und wo die Kapselung endet
Custom Elements registrieren eine Klasse unter einem Tag-Namen mit Bindestrich samt Lifecycle-Callbacks; Shadow DOM gibt ihr einen abgegrenzten Teilbaum, dessen Stile in keine Richtung durchsickern; Templates und deklarative Shadow Roots liefern Markup. Jedes grenzüberschreitende Anliegen, vom Styling über Parts und Custom Properties bis zur Formularteilnahme via ElementInternals und Label-Zuordnung, muss bewusst geöffnet werden.
-
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 Vitals: Was LCP, INP und CLS messen
Core Web Vitals sind drei Feldmetriken: Largest Contentful Paint (Renderzeit des grössten sichtbaren Elements, Ziel 2,5 s), Interaction to Next Paint (längste Interaktionslatenz, Ziel 200 ms) und Cumulative Layout Shift (unerwartete Bewegung, Ziel 0,1), jeweils am 75. Perzentil der Seitenaufrufe beurteilt.
-
Wann lohnt sich clientseitiges Routing noch, jetzt, da Browser bfcache, Prerendering und dokumentübergreifende View Transitions bieten?
Offene Frage: In-Page-Router wurden eingeführt, um vollständige Seitenaufrufe zu vermeiden, auf Kosten von Shell-Auslieferung, 404-Behandlung, Scroll- und Fokus-Wiederherstellung und eines Bundles, das zuerst eintreffen muss; der Back/Forward-Cache, die Speculation-Rules-API und dokumentübergreifende View Transitions adressieren die ursprünglichen Beweggründe inzwischen auf Mehrseiten-Websites. Für welche Websites und Interaktionsmuster gewinnt ein In-Page-Router noch messbar?
-
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.
-
Datei-Uploads von Nutzern validieren, speichern und ausliefern
Nur die Dateitypen akzeptieren, die das Feature braucht; den Typ per Erlaubnisliste der Endung plus Inhaltsprüfung bestimmen statt über den Content-Type des Clients; auf eine zufällige Kennung umbenennen; Grössenlimiten vor und nach der Dekomprimierung durchsetzen; ausserhalb des Web-Roots oder auf einem separaten Host speichern und über einen Handler ausliefern, der Typ, nosniff und Content-Disposition setzt, idealerweise von einem separaten Ursprung aus.
Maschinenlesbar: JSON