HEAD und OPTIONS: was sie beantworten und wofür Clients sie nutzen

Worum es geht

HEAD ist gemäss RFC 9110 identisch mit GET, ausser dass der Server keinen Inhalt senden darf (MUST NOT). Der Server sollte dieselben Header-Felder senden wie bei GET, darf aber Felder weglassen, deren Wert erst beim Erzeugen des Inhalts bekannt wird, etwa Content-Length oder Vary bei einer gepufferten dynamischen Antwort. Ein Rumpf in einer HEAD-Anfrage hat keine definierte Bedeutung und kann dazu führen, dass die Verbindung wegen Verdachts auf Request Smuggling geschlossen wird. HEAD-Antworten sind cachefähig, und gemäss RFC 9111 nutzt ein Cache eine HEAD-Antwort, um eine gespeicherte GET-Antwort zu aktualisieren, wenn die Validatoren und Content-Length übereinstimmen, und behandelt sie andernfalls als veraltet.

OPTIONS erfragt Informationen über die Kommunikationsoptionen einer Ressource oder, wenn das Ziel * ist, des Servers als Ganzes; RFC 9110 beschreibt dies als eine Art Ping, der Fähigkeiten testet, ohne eine Ressourcenaktion zu implizieren. Eine erfolgreiche Antwort sollte Header enthalten, die optionale Merkmale beschreiben, insbesondere Allow; das Format des Rumpfs ist nicht definiert; Antworten sind durch HTTP-Caches nicht cachefähig; Max-Forwards kann einen bestimmten Proxy in der Kette adressieren. Bei CORS sendet der Browser einen OPTIONS-Preflight mit Access-Control-Request-Method und Access-Control-Request-Headers und erwartet die passenden Access-Control-Allow-*-Header zurück; MDN merkt an, dass für diese Antwort sowohl 200 als auch 204 zulässig sind, einige Browser 204 aber fehlerhaft behandelt haben.

Warum es wichtig ist

Link-Prüfer, Download-Manager (die Content-Length und Accept-Ranges lesen), Verfügbarkeitsmonitore und Crawler verlassen sich auf HEAD; ein Framework, das HEAD mit 405 beantwortet oder andere Header als GET liefert, lässt sie falsch berichten. OPTIONS ist das, was ein Browser vor jeder nicht-einfachen Cross-Origin-Anfrage sendet; eine API, die darauf mit 404, 401 oder einer Weiterleitung antwortet, ist aus Browsern unabhängig von ihren CORS-Headern unbrauchbar.

So wird es angewendet

• HEAD automatisch aus jeder GET-Route ableiten; Status, Content-Type, ETag und Last-Modified identisch halten und die Erzeugung des Rumpfs nach Möglichkeit überspringen.
• Für HEAD dieselbe Autorisierung wie für GET anwenden; die Existenz geschützter Ressourcen nicht durch einen abweichenden Status preisgeben.
• OPTIONS mit einem aus dem Router berechneten Allow beantworten (und Allow auch in 405-Antworten aufnehmen, wie von RFC 9110 verlangt).
• Preflights vor der Authentifizierung behandeln: MDN hält fest, dass Preflight-Anfragen niemals Credentials enthalten dürfen. Access-Control-Max-Age setzen, damit der Browser das Ergebnis cacht.
• OPTIONS * explizit routen; pfadbasierte Router machen daraus oft ein 404.

Stolpersteine

Eine HEAD-Antwort kann Transfer-Encoding: chunked tragen und trotzdem keinen Rumpf haben. Middleware, die Content-Length durch Rendern des Rumpfs berechnet, unterläuft den Zweck von HEAD. Der CORS-Preflight-Cache und der HTTP-Cache sind getrennte Mechanismen; nicht Cache-Control, sondern Access-Control-Max-Age bestimmt, wie lange ein Browser ein Preflight-Ergebnis behält.