7. Server Processing Model (Server-Verarbeitungsmodell)

Dieser Abschnitt beschreibt das Verarbeitungsmodell für HSTS-Host-Implementierungen. Das Modell hat zwei Aspekte: Der erste betrifft die Verarbeitungsregeln für HTTP-Anforderungsnachrichten, die über einen sicheren Transport empfangen werden (TLS [RFC5246] oder SSL [RFC6101]; siehe auch Abschnitt 14.1 ("Underlying Secure Transport Considerations")), und der zweite betrifft die Verarbeitungsregeln für HTTP-Anforderungsnachrichten, die über einen unsicheren Transport (z. B. TCP) empfangen werden.

7.1. HTTP-over-Secure-Transport Request Type (HTTP-über-sicheren-Transport-Anforderungstyp)

Bei der Beantwortung einer HTTP-Anforderung, die über einen sicheren Transport kommuniziert wird, sollte (SHOULD) ein HSTS-Host in seiner Antwortnachricht ein STS-Header-Feld enthalten, das die in Abschnitt 6.1 ("Strict-Transport-Security HTTP Response Header Field") spezifizierte Syntax erfüllen muss (MUST). Wenn ein STS-Header-Feld enthalten ist, muss (MUST) der HSTS-Host nur ein solches Header-Feld enthalten.

Das Etablieren eines bestimmten Hosts als bekannter HSTS-Host im Kontext eines bestimmten UA kann (MAY) über HTTP erfolgen, das auf einem sicheren Transport läuft, indem mindestens ein gültiges STS-Header-Feld korrekt (gemäß dieser Spezifikation) an den UA zurückgegeben wird. Andere Mechanismen können (MAY) ebenfalls verwendet werden, z. B. eine clientseitig vorgeladene Liste bekannter HSTS-Hosts; siehe z. B. Abschnitt 12 ("User Agent Implementation Advice").

HINWEIS: Das Einschließen des STS-Header-Felds wird als "sollte (SHOULD)" spezifiziert, um verschiedene serverseitige und netzwerkseitige Caching- und Lastausgleichskonfigurationen zu berücksichtigen, in denen es schwierig sein kann, das STS-Header-Feld im Namen eines bestimmten HSTS-Hosts einheitlich auszugeben.

7.2. HTTP Request Type (HTTP-Anforderungstyp)

Wenn ein HSTS-Host eine HTTP-Anforderungsnachricht über einen unsicheren Transport empfängt, sollte (SHOULD) er eine HTTP-Antwortnachricht senden, die einen Statuscode enthält, der eine permanente Umleitung anzeigt, z. B. Statuscode 301 (Abschnitt 10.3.2 von [RFC2616]), und einen Location-Header-Feldwert, der entweder den ursprünglichen effektiven Anforderungs-URI der HTTP-Anforderung (siehe Abschnitt 9 ("Constructing an Effective Request URI")) enthält, der bei Bedarf so modifiziert wurde, dass er ein URI-Schema von "https" hat, oder einen URI mit einem URI-Schema von "https", der gemäß der lokalen Richtlinie generiert wurde.

HINWEIS: Das obige Verhalten ist "sollte (SHOULD)" statt "muss (MUST)" aus folgenden Gründen:

• Risiken der serverseitigen Umleitung von unsicher zu sicher [OWASP-TLSGuide].

• Bereitstellungsmerkmale der Site. Beispielsweise funktioniert eine Site mit Drittanbieterkomponenten möglicherweise nicht ordnungsgemäß, wenn sie eine serverseitige Umleitung von unsicher zu sicher ausführt, wenn über unsicheren Transport zugegriffen wird, funktioniert aber ordnungsgemäß, wenn sie einheitlich über sicheren Transport zugegriffen wird. Letzteres ist die Situation, wenn ein UA, der HSTS unterstützt, die Site bereits (durch beliebige Mittel, z. B. vorherige Interaktion oder UA-Konfiguration) als bekannten HSTS-Host notiert hat.

Ein HSTS-Host darf nicht (MUST NOT) das STS-Header-Feld in HTTP-Antworten einschließen, die über unsicheren Transport übermittelt werden.