Zum Hauptinhalt springen

6. Syntax (Syntax)

Dieser Abschnitt definiert die Syntax des HTTP-Antwort-Header-Felds Strict-Transport-Security und seiner Direktiven und bietet einige Beispiele.

Anschließend beschreibt Abschnitt 7 ("Server Processing Model") detailliert, wie Hosts dieses Header-Feld verwenden, um ihre HSTS-Richtlinie zu deklarieren, und Abschnitt 8 ("User Agent Processing Model") beschreibt detailliert, wie Benutzeragenten das Header-Feld verarbeiten und die HSTS-Richtlinie anwenden.

6.1. Strict-Transport-Security HTTP Response Header Field (Strict-Transport-Security HTTP-Antwort-Header-Feld)​

Das HTTP-Antwort-Header-Feld Strict-Transport-Security (STS-Header-Feld) weist den UA an, dass er eine HSTS-Richtlinie auf den Host anwenden muss (MUST), der die Antwortnachricht mit diesem Header-Feld ausgegeben hat.

Die ABNF-Syntax (Augmented Backus-Naur Form) des STS-Header-Felds lautet wie folgt. Sie basiert auf der in Abschnitt 2 von [RFC2616] definierten generischen Syntax (die das Konzept des "impliziten linearen Leerraums (implied linear whitespace)", auch bekannt als "implizites *LWS", einschließt).

Strict-Transport-Security = "Strict-Transport-Security" ":"
                            [ directive ]  *( ";" [ directive ] )

directive                 = directive-name [ "=" directive-value ]
directive-name            = token
directive-value           = token | quoted-string

Wobei:

token          = <token, defined in [RFC2616], Section 2.2>
quoted-string  = <quoted-string, defined in [RFC2616], Section 2.2>

Die beiden in dieser Spezifikation definierten Direktiven sind nachfolgend beschrieben. Die allgemeinen Anforderungen für Direktiven sind:

  1. Die Reihenfolge, in der Direktiven erscheinen, ist nicht wichtig.

  2. Alle Direktiven müssen (MUST) im STS-Header-Feld nur einmal erscheinen. Direktiven sind optional oder erforderlich, wie in ihrer Definition festgelegt.

  3. Direktivennamen sind nicht case-sensitiv.

  4. UAs müssen (MUST) jedes STS-Header-Feld ignorieren, das eine Direktive oder andere Header-Feld-Wertdaten enthält, die nicht der in dieser Spezifikation definierten Syntax entsprechen.

  5. Wenn das STS-Header-Feld eine Direktive enthält, die der UA nicht erkennt, muss (MUST) der UA die nicht erkannte Direktive ignorieren, und wenn das STS-Header-Feld ansonsten die oben genannten Anforderungen (1 bis 4) erfüllt, muss (MUST) der UA die erkannten Direktiven verarbeiten.

Zusätzliche Direktiven, die die semantischen Funktionen des STS-Header-Felds erweitern, können in anderen Spezifikationen definiert werden, sofern ein Register dafür definiert wird (mit der IANA-Richtliniendefinition IETF Review [RFC5226]).

HINWEIS: Solche zukünftigen Direktiven werden von UAs ignoriert, die nur diese Spezifikation implementieren, sowie von allgemein nicht konformen UAs. Siehe Abschnitt 14.2 ("Non-Conformant User Agent Implications") für weitere Diskussionen.

6.1.1. The max-age Directive (Die max-age-Direktive)​

Die erforderliche (REQUIRED) "max-age"-Direktive gibt die Anzahl der Sekunden an, nach dem Empfang des STS-Header-Felds, während derer der UA den Host (von dem die Nachricht empfangen wurde) als bekannten HSTS-Host behandelt. Siehe auch Abschnitt 8.1.1 ("Noting an HSTS Host - Storage Model"). Die delta-seconds-Produktion ist in [RFC2616] spezifiziert.

Die Syntax des erforderlichen (REQUIRED) Werts der max-age-Direktive (nach dem Escaping der Zeichenkette in Anführungszeichen, falls erforderlich) ist wie folgt definiert:

max-age-value = delta-seconds

delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>

HINWEIS: Ein max-age-Wert von Null (d. h. "max-age=0") signalisiert dem UA, den Host nicht mehr als bekannten HSTS-Host zu behandeln, einschließlich der includeSubDomains-Direktive, falls sie für diesen HSTS-Host behauptet wurde. Siehe auch Abschnitt 8.1 ("Strict-Transport-Security Response Header Field Processing").

6.1.2. The includeSubDomains Directive (Die includeSubDomains-Direktive)​

Die optionale (OPTIONAL) "includeSubDomains"-Direktive ist eine wertlose Direktive, die, falls vorhanden (d. h. sie wird "behauptet"), dem UA signalisiert, dass die HSTS-Richtlinie für diesen HSTS-Host sowie für alle Subdomains des Domainnamens des Hosts gilt.

6.2. Examples (Beispiele)​

Das folgende HSTS-Header-Feld legt fest, dass die HSTS-Richtlinie ein Jahr lang gültig bleibt (etwa 31536000 Sekunden in einem Jahr), und dass die Richtlinie nur für die Domain des HSTS-Hosts gilt, der sie ausgegeben hat:

Strict-Transport-Security: max-age=31536000

Das folgende HSTS-Header-Feld legt fest, dass die HSTS-Richtlinie etwa sechs Monate lang gültig bleibt, und dass die Richtlinie für die Domain des ausgebenden HSTS-Hosts und alle ihre Subdomains gilt:

Strict-Transport-Security: max-age=15768000 ; includeSubDomains
Letztes Update am