HTTP Host Header

Typ

Der Host-Header ist ein obligatorischer Request-Header in HTTP/1.1, der den Ziel-Hostnamen und optionalen Port identifiziert.

Syntax

Der Header enthält einen Hostnamen (Domain oder IP-Adresse) und optional einen Port, getrennt durch Doppelpunkt.

http 
Host: api.example.com
Host: api.example.com:8443

Direktiven

Der Host-Header besteht aus Hostname und optionalem Port, wobei der Default-Port des Protokolls (80 für HTTP, 443 für HTTPS) weggelassen werden kann.

hostname
Domain-Name (FQDN) oder IP-Adresse des Ziel-Servers (IPv4 oder IPv6 in Brackets).
port
Optionale Port-Nummer, wenn vom Standard-Port abweichend (Default: 80 für http, 443 für https).

Beispiele

Die folgenden Beispiele zeigen typische Anwendungsfälle für Virtual Hosting, API-Versioning via Subdomains und Multi-Tenant-Routing.

API-Gateway mit Virtual Hosting

Ein API-Gateway routet Anfragen basierend auf dem Host-Header zu unterschiedlichen Backend-Services.

http 
GET /api/v1/users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json

Multi-Tenant-System mit Subdomain-Routing

Ein SaaS-System identifiziert den Tenant via Subdomain im Host-Header und isoliert Daten entsprechend.

http 
POST /api/orders HTTP/1.1
Host: acme-corp.api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

{
  "productId": "prod_789",
  "quantity": 5
}

API-Versioning via Subdomain

Ein API-Provider nutzt Subdomains für Major-Versionen und ermöglicht parallelen Betrieb verschiedener API-Versionen.

http 
GET /products/12345 HTTP/1.1
Host: v2.api.example.com
Accept: application/json
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Host-Header-Routing-Flow

Der Host-Header steuert das Routing in API-Gateways und Load Balancern für Multi-Tenant- und Virtual-Hosting-Szenarien.

plantuml 
@startuml
!theme plain
skinparam BoxPadding 20
skinparam ParticipantPadding 20

participant "Client" as client
participant "API\nGateway" as gateway
participant "Tenant A\nService" as tenantA
participant "Tenant B\nService" as tenantB
participant "Public API\nService" as publicAPI

client -> gateway: GET /api/orders\nHost: acme-corp.api.example.com
gateway -> gateway: Parse Host-Header\nExtract tenant: acme-corp
gateway -> tenantA: GET /api/orders\nX-Tenant-ID: acme-corp
tenantA --> gateway: 200 OK\n[Orders JSON]
gateway --> client: 200 OK

client -> gateway: GET /api/products\nHost: widgets-inc.api.example.com
gateway -> gateway: Parse Host-Header\nExtract tenant: widgets-inc
gateway -> tenantB: GET /api/products\nX-Tenant-ID: widgets-inc
tenantB --> gateway: 200 OK\n[Products JSON]
gateway --> client: 200 OK

client -> gateway: GET /api/status\nHost: api.example.com
gateway -> gateway: Parse Host-Header\nNo tenant → public API
gateway -> publicAPI: GET /api/status
publicAPI --> gateway: 200 OK\n{"status": "operational"}
gateway --> client: 200 OK

note over gateway: Host-Header ermöglicht\nTenant-Isolation\nohne zusätzliche\nRequest-Parameter
@enduml

Vorteile für die Systemarchitektur

  • Virtual Hosting für mehrere APIs auf einer IP-Adresse
  • Multi-Tenant-Isolation via Subdomain-basiertes Routing
  • API-Versioning durch Subdomain-Strategie (v1.api.example.com, v2.api.example.com)
  • Domain-basierte Authentifizierung und Rate-Limiting-Policies
  • Obligatorisch in HTTP/1.1, automatisch von HTTP-Clients gesetzt

Spezifikation

RFC 9110 (HTTP Semantics) definiert den Host-Header als obligatorischen Request-Header in HTTP/1.1 für Virtual-Hosting-Funktionalität.

Weitere Spezifikationen

Origin Header, X-Forwarded-Host Header