7. Server Processing Model (Modello di Elaborazione del Server)

Questa sezione descrive il modello di elaborazione per le implementazioni degli host HSTS. Il modello ha due aspetti: il primo riguarda le regole di elaborazione per i messaggi di richiesta HTTP ricevuti tramite trasporto sicuro (TLS [RFC5246] o SSL [RFC6101]; vedere anche la sezione 14.1 ("Underlying Secure Transport Considerations")), e il secondo riguarda le regole di elaborazione per i messaggi di richiesta HTTP ricevuti tramite trasporto non sicuro (ad esempio, TCP).

7.1. HTTP-over-Secure-Transport Request Type (Tipo di Richiesta HTTP su Trasporto Sicuro)

Nella risposta a una richiesta HTTP comunicata tramite trasporto sicuro, un host HSTS dovrebbe (SHOULD) includere nel suo messaggio di risposta un campo di intestazione STS che deve (MUST) soddisfare la sintassi specificata nella sezione 6.1 ("Strict-Transport-Security HTTP Response Header Field"). Se viene incluso un campo di intestazione STS, l'host HSTS deve (MUST) includere un solo tale campo di intestazione.

Stabilire un dato host come host HSTS conosciuto, nel contesto di un dato UA, può (MAY) essere realizzato tramite HTTP in esecuzione su trasporto sicuro restituendo correttamente (conformemente a questa specifica) almeno un campo di intestazione STS valido al UA. Possono (MAY) essere utilizzati anche altri meccanismi, ad esempio un elenco precaricato lato client di host HSTS conosciuti; vedere ad esempio la sezione 12 ("User Agent Implementation Advice").

NOTA: L'inclusione del campo di intestazione STS è specificata come "dovrebbe (SHOULD)" per accogliere varie configurazioni di caching lato server e lato rete e di bilanciamento del carico, in cui potrebbe essere difficile emettere uniformemente il campo di intestazione STS per conto di un dato host HSTS.

7.2. HTTP Request Type (Tipo di Richiesta HTTP)

Se un host HSTS riceve un messaggio di richiesta HTTP tramite trasporto non sicuro, dovrebbe (SHOULD) inviare un messaggio di risposta HTTP contenente un codice di stato che indica un reindirizzamento permanente, come il codice di stato 301 (sezione 10.3.2 di [RFC2616]), e un valore del campo di intestazione Location contenente l'URI di richiesta effettivo originale della richiesta HTTP (vedere la sezione 9 ("Constructing an Effective Request URI")), modificato come necessario per avere uno schema URI di "https", o un URI con uno schema URI di "https" generato secondo la politica locale.

NOTA: Il comportamento sopra descritto è "dovrebbe (SHOULD)" piuttosto che "deve (MUST)" per i seguenti motivi:

• Rischi di reindirizzamento lato server da non sicuro a sicuro [OWASP-TLSGuide].

• Caratteristiche di distribuzione del sito. Ad esempio, un sito contenente componenti di terze parti potrebbe non funzionare correttamente quando esegue un reindirizzamento lato server da non sicuro a sicuro quando vi si accede tramite trasporto non sicuro, ma funziona correttamente quando vi si accede uniformemente tramite trasporto sicuro. Quest'ultima è la situazione quando un UA che supporta HSTS ha già (con qualsiasi mezzo, ad esempio interazione precedente o configurazione UA) annotato il sito come host HSTS conosciuto.

Un host HSTS non deve (MUST NOT) includere il campo di intestazione STS nelle risposte HTTP trasmesse tramite trasporto non sicuro.