HEAD

Verwendung

Eine HEAD-Anfrage ruft Metadaten zu einer Ressource ab: Größe, Typ, Frische und Existenz. Der Server verarbeitet die Anfrage genau wie ein GET, bricht jedoch vor dem Übertragen des Bodys ab. Alle Antwort-Header, einschließlich Content-Length und Content-Type, entsprechen denen einer vollständigen GET-Antwort.

Häufige Anwendungsfälle

Link-Validierung. Automatisierte Werkzeuge senden HEAD-Anfragen, um zu überprüfen, ob URLs ein 200 zurückgeben, ohne vollständige Seiten herunterzuladen. Defekte Links zeigen sich als 404- oder 410-Antworten.

Monitoring und Health-Checks. Uptime-Monitore prüfen Endpunkte mit HEAD, um deren Verfügbarkeit zu bestätigen. Die geringere Antwortgröße reduziert die Bandbreite und beschleunigt die Abfrageintervalle.

Sondierung der Inhaltsaushandlung. Clients sehen sich die Header Content-Type, Content-Encoding und Content-Language an, bevor sie entscheiden, ob sie die vollständige Ressource abrufen.

Cache-Validierung. Eine HEAD-Antwort mit ETag oder Last-Modified erlaubt es Caches, die Frische zu prüfen, ohne den Body herunterzuladen. Weisen die Header der HEAD-Antwort darauf hin, dass eine zwischengespeicherte Kopie veraltet ist, markiert der Cache den Eintrag entsprechend.

Abschätzung der Downloadgröße. Dateimanager und Download-Werkzeuge lesen Content-Length aus einer HEAD-Antwort, um die Dateigröße anzuzeigen oder Speicherplatz zu reservieren, bevor die Übertragung beginnt.

Hinweis

Ein Anfrage-Body in einer HEAD-Anfrage hat keine allgemein definierte Semantik. Manche Implementierungen weisen HEAD-Anfragen mit Body zurück. Das Mitsenden eines Bodys birgt das Risiko, Request-Smuggling-Schwachstellen in Vermittlern auszulösen, die das Message Framing falsch parsen.

Beispiel

Eine HEAD-Anfrage, um zu prüfen, ob eine Ressource existiert, und um die Antwort-Header einzusehen. Der Server gibt 200 mit Inhaltsmetadaten, aber ohne Body zurück.

Anfrage

HEAD /report.pdf HTTP/1.1
Host: example.com

Antwort

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Length: 284750
Last-Modified: Mon, 10 Feb 2025 08:30:00 GMT
ETag: "f47ac10b"

Der Content-Length-Header zeigt, dass die Datei rund 278 KB groß ist. Die Header Last-Modified und ETag liefern Validatoren für bedingte Anfragen bei nachfolgenden Abrufen.

CORS

HEAD ist eine CORS-safelisted Methode. Cross-Origin-HEAD-Anfragen lösen keine Preflight-Anfrage aus und folgen damit demselben Safelist-Verhalten wie GET.

HEAD im Vergleich zu GET

HEAD gibt dieselben Header zurück wie GET, lässt den Antwort-Body jedoch vollständig weg. Das macht HEAD schneller und bandbreitenschonender für Aufgaben, die nur Metadaten benötigen.

Zu den verbreiteten Anwendungen zählen die Prüfung, ob eine Ressource existiert, das Auslesen von Content-Length für die Dateigröße, das Einsehen von Last-Modified-Daten und das Beschaffen von Cache-Validatoren wie ETag, ohne die vollständige Ressource herunterzuladen.

Manche Server implementieren HEAD, indem sie intern den vollständigen GET-Handler ausführen und den Body vor dem Senden der Antwort entfernen. In diesen Fällen beschränkt sich der Leistungsvorteil allein auf die eingesparte Übertragungszeit für die Body-Bytes.

HEAD-Antworten aktualisieren außerdem zwischengespeicherte GET-Antworten. Sendet ein Cache eine HEAD-Anfrage und stimmen die zurückgegebenen Validatoren mit einem gespeicherten GET-Eintrag überein, frischt der Cache die gespeicherten Header entsprechend auf.

SEO-Auswirkung

Such-Crawler rufen Seiten mit GET ab, nicht mit HEAD, daher steuert HEAD die Indexierung nicht. HEAD bleibt nützlich für Link-Checker, Uptime-Monitore und SEO-Audit-Werkzeuge, die bestätigen, dass eine URL ein 200 zurückgibt, ohne den Body herunterzuladen.