HTTP Priority Header

Der HTTP-Header Priority ist ein Request- und Response-Header für HTTP/2 und HTTP/3, der die Dringlichkeit und Verarbeitungsreihenfolge von Requests signalisiert. Server können Ressourcen entsprechend priorisieren und optimale Reihenfolgen für parallele Streams wählen.

Typ

Request-Header, Response-Header

Syntax

Der Header definiert Dringlichkeit und inkrementelle Verarbeitung für Ressourcen.

http 
Priority: u=3
Priority: u=0, i
Priority: u=7, i

Direktiven

Die Direktiven steuern Priorisierung und Verarbeitungsstrategie für HTTP-Streams.

u=<urgency>
Dringlichkeitsstufe von 0 (höchste Priorität) bis 7 (niedrigste Priorität). Standard ist u=3.
i
Incremental-Flag signalisiert, dass Ressource in Teilen gesendet werden kann, nicht atomisch. Nützlich für große Dateien oder Streaming-Content.

Beispiele

Nachfolgend finden Sie praktische Anwendungsbeispiele für den Priority-Header.

Beispiel 1 Kritische API-Daten mit höchster Priorität

http 
GET /api/user/session HTTP/2
Host: api.example.com
Priority: u=0
Authorization: Bearer eyJhbGciOiJIUzI1...

Session-Daten werden mit höchster Dringlichkeit angefordert, Server priorisiert diesen Request vor allen anderen.

Beispiel 2 Hintergrund-Synchronisation mit niedriger Priorität

http 
POST /api/analytics/events HTTP/2
Host: api.example.com
Priority: u=6
Content-Type: application/json

[{"event": "page_view", "timestamp": 1710512345}]

Analytics-Events haben niedrige Priorität, Server kann andere kritische Requests zuerst bearbeiten.

Beispiel 3 Große Datei mit inkrementeller Übertragung

http 
GET /api/exports/report-2024.csv HTTP/2
Host: api.example.com
Priority: u=4, i

Server kann Report in Chunks senden, während andere Requests parallel bearbeitet werden.

Resource Prioritization Flow

HTTP/2 Ressourcen-Priorisierung mit Priority Header

Vorteile für die Systemarchitektur

Explizite Request-Priorisierung optimiert Ressourcennutzung und User Experience.

  • Optimale Ladeperformanz: Kritische API-Calls werden zuerst bearbeitet, Time-to-Interactive sinkt
  • Bandbreiten-Management: Server können Netzwerk-Ressourcen effizienter auf Basis von Dringlichkeit verteilen
  • Backend-Skalierung: Worker-Pools können Requests nach Priorität abarbeiten statt nach FIFO-Prinzip

Spezifikation

RFC 9218 – Extensible Prioritization Scheme for HTTP https://www.rfc-editor.org/rfc/rfc9218.html

Weitere Spezifikationen

Server-Timing Header, GET Method