HTTP Expect Header

Typ

Der Expect-Header ist ein HTTP-Request-Header, mit dem der Client Server-Verhalten vor der Übertragung des Request-Body anfordert.

Syntax

Der Header definiert Erwartungen an das Server-Verhalten vor vollständiger Request-Übertragung.

http 
Expect: 100-continue

Direktiven

Der Expect-Header verwendet standardisierte Erwartungs-Werte:

100-continue
Fordert Server auf, 100 Continue zu senden bevor Client den Request-Body überträgt. Server validiert Header zuerst und sendet 100 oder Fehlerstatus.
expectation-failed
Wenn Server die Erwartung nicht erfüllen kann, antwortet er mit 417 Expectation Failed. Client entscheidet dann über weiteres Vorgehen.
other-expectations
Nur 100-continue ist standardisiert. Server sollten unbekannte Erwartungen mit 417 ablehnen.

Beispiele

Große Datei-Upload mit 100-Continue

Ein Client möchte eine große Datei hochladen:

http 
POST /api/v1/files/upload HTTP/1.1
Host: storage.example.com
Expect: 100-continue
Content-Type: application/octet-stream
Content-Length: 104857600
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Server validiert Authorization und Quota vor Upload:

http 
HTTP/1.1 100 Continue

Client sendet jetzt den 100MB Request-Body:

http 
[100MB binäre Datei-Daten]

Server antwortet nach vollständigem Upload:

http 
HTTP/1.1 201 Created
Location: /api/v1/files/file-abc123
Content-Type: application/json

{
  "file_id": "file-abc123",
  "size": 104857600,
  "status": "uploaded"
}

Server lehnt Request vor Body-Upload ab

Ein Client versucht Upload ohne gültige Authorization:

http 
POST /api/v1/files/upload HTTP/1.1
Host: storage.example.com
Expect: 100-continue
Content-Type: application/octet-stream
Content-Length: 104857600
Authorization: Bearer invalid_token

Server lehnt ohne Body-Übertragung ab:

http 
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="API"
Content-Type: application/json

{
  "error": "invalid_token",
  "message": "Authorization token is invalid or expired"
}

Client spart Bandbreite durch nicht gesendeten Body.

API-Gateway validiert Quota vor großem Upload

Ein Client nähert sich seinem Upload-Limit:

http 
POST /api/v1/documents HTTP/1.1
Host: api.example.com
Expect: 100-continue
Content-Type: application/pdf
Content-Length: 52428800
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Gateway prüft Quota und lehnt ab:

http 
HTTP/1.1 507 Insufficient Storage
Retry-After: 86400
Content-Type: application/json

{
  "error": "quota_exceeded",
  "message": "Monthly upload quota of 1GB exceeded",
  "quota_reset": "2025-11-01T00:00:00Z"
}

Expect-100-Continue-Flow

Der Ablauf des 100-Continue-Handshakes für optimierte große Uploads.

plantuml 
@startuml
actor Client
participant "API Gateway" as Gateway
participant "Auth Service" as Auth
participant "Storage Service" as Storage

Client -> Gateway: POST /api/v1/files\nExpect: 100-continue\nContent-Length: 100MB\nAuthorization: Bearer token\n(no body yet)

Gateway -> Auth: Validate token

alt Valid token and quota available
  Auth --> Gateway: Token valid\nQuota: 500MB available
  Gateway --> Client: 100 Continue

  Client -> Gateway: [100MB request body]
  Gateway -> Storage: Store file
  Storage --> Gateway: Stored successfully
  Gateway --> Client: 201 Created\nLocation: /files/abc123

else Invalid token
  Auth --> Gateway: Token invalid
  Gateway --> Client: 401 Unauthorized\n(body never sent, bandwidth saved)

else Quota exceeded
  Auth --> Gateway: Token valid\nQuota: 10MB available
  Gateway --> Client: 507 Insufficient Storage\n(body never sent)
end

note right
100-Continue saves bandwidth
by validating request headers
before large body transmission
end note
@enduml

Vorteile für die Systemarchitektur

  • Spart Bandbreite durch frühzeitige Ablehnung ungültiger Requests vor Body-Upload
  • Reduziert Server-Last durch Validierung von Authorization und Quota vor Datenverarbeitung
  • Verbessert User Experience durch schnellere Fehler-Responses bei großen Uploads
  • Ermöglicht effiziente Quota-Enforcement ohne unnötige Datenübertragung
  • Standardisierter Mechanismus ohne zusätzliche API-spezifische Validierungs-Endpoints

Spezifikation

Der Expect-Header ist in RFC 9110 Section 10.1.1 (HTTP Semantics) definiert.

Weitere Spezifikationen

HTTP Status 100 - Continue, HTTP Status 417 - Expectation Failed