2. Campi di Intestazione Cache-Control Mirati

Un Campo di Intestazione Cache-Control Mirato (di seguito "campo mirato") è un campo di intestazione di risposta HTTP che ha la stessa semantica del campo di intestazione di risposta Cache-Control ([HTTP-CACHING], Sezione 5.2). Tuttavia, ha un nome di campo distinto che indica il target per le sue direttive di cache.

Ad esempio:

CDN-Cache-Control: max-age=60

è un campo mirato che si applica ai CDN, come definito nella Sezione 3.

2.1. Sintassi

I campi mirati sono Campi Strutturati Dizionario (Sezione 3.2 di [STRUCTURED-FIELDS]). Ogni membro del Dizionario è una direttiva di risposta di cache HTTP (Sezione 5.2.2 di [HTTP-CACHING]) incluse le direttive di risposta di estensione (secondo la Sezione 5.2.3 di [HTTP-CACHING]). Si noti che, sebbene i campi mirati abbiano spesso la stessa sintassi dei campi Cache-Control, le differenze nella gestione degli errori significano che l'utilizzo di un parser Cache-Control anziché di un parser di Campi Strutturati può introdurre problemi di interoperabilità.

Poiché le direttive di cache non sono definite in termini di tipi di dati strutturati, è necessario mappare i loro valori nei tipi appropriati. La Sezione 5.2 di [HTTP-CACHING] definisce i valori delle direttive di cache come assenti, una stringa tra virgolette o un token.

Ciò significa che le direttive di cache che non hanno valore saranno mappate su un Booleano (Sezione 3.3.6 di [STRUCTURED-FIELDS]). Quando il valore è una stringa tra virgolette, verrà mappato su una Stringa (Sezione 3.3.3 di [STRUCTURED-FIELDS]), e quando è un token, verrà mappato su un Token (Sezione 3.3.4 di [STRUCTURED-FIELDS]), un Intero (Sezione 3.3.1 di [STRUCTURED-FIELDS]) o un Decimale (Sezione 3.3.2 di [STRUCTURED-FIELDS]), a seconda del contenuto del valore.

Ad esempio, la direttiva max-age (Sezione 5.2.2.1 di [HTTP-CACHING]) ha un valore intero; no-store (Sezione 5.2.2.5 di [HTTP-CACHING]) ha sempre un valore booleano true, e no-cache (Sezione 5.2.2.4 di [HTTP-CACHING]) ha un valore che può essere booleano true o una stringa contenente un elenco delimitato da virgole di nomi di campi.

Le implementazioni NON DEVONO (MUST NOT) generare valori che violano questi vincoli inferiti sul valore della direttiva di cache. In particolare, i valori di stringa il cui primo carattere non è alfabetico o "*" DEVONO (MUST) essere generati come Stringhe in modo da non essere confusi con altri tipi.

Le implementazioni NON DOVREBBERO (SHOULD NOT) consumare valori che violano questi vincoli inferiti. Ad esempio, un'implementazione consumante che costringe un max-age con un valore decimale in un intero si comporterebbe diversamente da altre implementazioni, causando potenzialmente problemi di interoperabilità.

I parametri ricevuti sulle direttive di cache devono essere ignorati, a meno che non sia esplicitamente specificata un'altra gestione.

Se un campo mirato in una data risposta è vuoto, o viene rilevato un errore di parsing, quel campo DEVE (MUST) essere ignorato dalla cache (cioè, si comporta come se il campo non fosse presente, probabilmente ricorrendo ad altri meccanismi di controllo della cache presenti).

2.2. Comportamento della cache

Una cache che implementa questa specifica mantiene un elenco di destinazione. Un elenco di destinazione è un elenco ordinato dei nomi dei campi mirati che utilizza per la politica di caching, con l'ordine che riflette la priorità dal più applicabile al meno applicabile. L'elenco di destinazione potrebbe essere fisso, configurabile dall'utente o generato per richiesta, a seconda dell'implementazione.

Ad esempio, una cache CDN potrebbe supportare sia CDN-Cache-Control che un'intestazione specifica per quel CDN, ExampleCDN-Cache-Control, con quest'ultima che sovrascrive la prima. Il suo elenco di destinazione sarebbe:

[ExampleCDN-Cache-Control, CDN-Cache-Control]

Quando una cache che implementa questa specifica riceve una risposta con uno o più dei nomi dei campi di intestazione nel suo elenco di destinazione, la cache DEVE (MUST) selezionare il primo (nell'ordine dell'elenco di destinazione) campo con un valore valido e non vuoto e utilizzare il suo valore per determinare la politica di caching per la risposta, e DEVE (MUST) ignorare i campi di intestazione Cache-Control ed Expires in quella risposta, a meno che non sia disponibile alcun valore valido e non vuoto dai campi di intestazione elencati.

Si noti che ciò avviene su base risposta per risposta; se nessun membro dell'elenco di destinazione della cache è presente, valido e non vuoto, una cache ricorre ad altri meccanismi di controllo della cache come richiesto da HTTP [HTTP-CACHING].

I campi mirati che non sono nell'elenco di destinazione di una cache NON DEVONO (MUST NOT) modificare il comportamento di quella cache e DEVONO (MUST) essere trasmessi.

Le cache che utilizzano un campo mirato DEVONO (MUST) implementare la semantica delle seguenti direttive di cache:

• max-age
• must-revalidate
• no-store
• no-cache
• private

Inoltre, DOVREBBERO (SHOULD) implementare altre direttive di cache (incluse le direttive di cache di estensione) che supportano nel campo di intestazione di risposta Cache-Control.

La semantica e la precedenza delle direttive di cache in un campo mirato sono le stesse di quelle in Cache-Control. In particolare, no-store e no-cache rendono max-age inoperante, e le direttive di estensione non riconosciute vengono ignorate.

2.3. Interazione con la freschezza HTTP

Il caching HTTP ha un singolo modello di freschezza end-to-end definito nella Sezione 4.2 di [HTTP-CACHING]. Quando meccanismi di freschezza aggiuntivi sono disponibili solo per alcune cache lungo un percorso di richiesta (ad esempio, utilizzando campi mirati), le loro interazioni devono essere attentamente considerate. In particolare, una cache mirata potrebbe avere durate di vita di freschezza più lunghe disponibili rispetto ad altre cache, causando la fornitura di risposte che appaiono prematuramente (o anche immediatamente) stantie per quelle altre cache, impattando negativamente sull'efficienza della cache.

Ad esempio, una risposta memorizzata da una cache CDN potrebbe essere fornita con le seguenti intestazioni:

Age: 1800
Cache-Control: max-age=600
CDN-Cache-Control: max-age=3600

Dal punto di vista del CDN, questa risposta è ancora fresca dopo essere stata memorizzata nella cache per 30 minuti, mentre dal punto di vista di altre cache, questa risposta è già stantia. Vedere [AGE-PENALTY] per ulteriori discussioni.

Quando la cache mirata ha un forte meccanismo di coerenza (ad esempio, il server di origine ha la capacità di invalidare proattivamente le risposte memorizzate nella cache), è spesso desiderabile mitigare questi effetti. Alcune tecniche viste nelle distribuzioni includono:

• Rimozione del campo di intestazione Age
• Aggiornamento del valore del campo di intestazione Date all'ora corrente
• Aggiornamento del valore del campo di intestazione Expires all'ora corrente, più qualsiasi valore Cache-Control: max-age

Questa specifica non pone requisiti specifici sulle implementazioni per mitigare questi effetti, ma le definizioni dei campi mirati possono farlo.

2.4. Definizione dei campi mirati

Un89→Un campo mirato per una particolare classe di cache può essere definito richiedendo la registrazione nel "Registro dei Nomi dei Campi del Protocollo di Trasferimento Ipertestuale (HTTP)" (<https://www.iana.org/assignments/http-fields/>).

Le richieste di registrazione possono utilizzare questo documento come documento di specifica; in tal caso, il campo Commenti dovrebbe definire chiaramente la classe di cache a cui si applica il campo mirato. In alternativa, se è stata creata altra documentazione per il campo, può essere utilizzata come documento di specifica.

Per convenzione, i campi mirati hanno il suffisso "-Cache-Control", ad esempio, "ExampleCDN-Cache-Control". Tuttavia, questo suffisso NON DEVE (MUST NOT) essere utilizzato da solo per identificare i campi mirati; è solo una convenzione.