5.2.2 Response Cache-Control Directives
Questa sezione definisce le direttive di cache che possono essere utilizzate da un server di origine o da un intermediario in una risposta HTTP.
5.2.2.1. must-revalidate
La direttiva di risposta "must-revalidate" indica che una volta che la risposta è diventata obsoleta, una cache NON DEVE (MUST NOT) utilizzare la risposta per soddisfare richieste successive senza una validazione riuscita sul server di origine.
La direttiva must-revalidate è necessaria per supportare il funzionamento affidabile di determinate funzionalità del protocollo. In tutte le circostanze, una cache DEVE (MUST) obbedire alla direttiva must-revalidate; in particolare, se una cache non può raggiungere il server di origine per qualsiasi motivo, DEVE (MUST) generare una risposta 504 (Gateway Timeout).
La direttiva must-revalidate dovrebbe (ought to) essere utilizzata dai server se e solo se il mancato successo della validazione di una richiesta potrebbe comportare un funzionamento errato, come una transazione finanziaria silenziosamente non eseguita.
5.2.2.2. no-cache
Argomento: #field-name (opzionale)
La direttiva di risposta "no-cache" indica che la risposta NON DEVE (MUST NOT) essere utilizzata per soddisfare una richiesta successiva senza una validazione riuscita sul server di origine. Ciò consente a un server di origine di impedire a una cache di utilizzare la risposta per soddisfare una richiesta senza contattarlo, anche da parte di cache che sono state configurate per inviare risposte obsolete.
Se la direttiva di risposta no-cache specifica uno o più nomi di campo, allora una cache PUÒ (MAY) utilizzare la risposta per soddisfare una richiesta successiva, soggetta a qualsiasi altra restrizione sul caching. Tuttavia, qualsiasi nome di campo specificato NON DEVE (MUST NOT) essere inviato nella risposta a una richiesta successiva senza una rivalidazione riuscita con il server di origine. Ciò consente a un server di origine di impedire il riutilizzo di determinati campi di intestazione in una risposta, pur consentendo il caching del resto della risposta.
Nota: La maggior parte delle cache HTTP/1.0 non riconoscerà o obbedirà a questa direttiva. Inoltre, le direttive di risposta no-cache con nomi di campo vengono spesso gestite dalle implementazioni come se fosse stata ricevuta una direttiva no-cache non qualificata; cioè, la gestione speciale per la forma qualificata non è ampiamente implementata.
5.2.2.3. no-store
La direttiva di risposta "no-store" indica che una cache NON DEVE (MUST NOT) memorizzare alcuna parte né della richiesta immediata né della risposta. Questa direttiva si applica sia alle cache private che a quelle condivise. "NON DEVE memorizzare" in questo contesto significa che la cache NON DEVE (MUST NOT) intenzionalmente memorizzare le informazioni in una memoria non volatile, e DEVE (MUST) fare un tentativo del miglior sforzo per rimuovere le informazioni dalla memoria volatile il più prontamente possibile dopo averle inoltrate.
Questa direttiva NON è un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, le cache malevole o compromesse potrebbero non riconoscere o obbedire a questa direttiva, e le reti di comunicazione potrebbero essere vulnerabili alle intercettazioni.
5.2.2.4. no-transform
La direttiva di risposta "no-transform" indica che un intermediario (indipendentemente dal fatto che implementi o meno una cache) NON DEVE (MUST NOT) trasformare il payload, come definito nella Sezione 5.7.2 di [RFC7230].
5.2.2.5. public
La direttiva di risposta "public" indica che qualsiasi cache PUÒ (MAY) memorizzare la risposta, anche se la risposta normalmente non sarebbe memorizzabile in cache o memorizzabile in cache solo all'interno di una cache privata. (Vedere anche la Sezione 3.2, che discute dell'effetto del campo di intestazione Authorization sulla memorizzabilità in cache.)
5.2.2.6. private
Argomento: #field-name (opzionale)
La direttiva di risposta "private" indica che la risposta è destinata a un singolo utente e NON DEVE (MUST NOT) essere memorizzata da una cache condivisa. Una cache privata PUÒ (MAY) memorizzare la risposta e riutilizzarla per richieste successive, anche se la risposta normalmente non sarebbe memorizzabile in cache.
Se la direttiva di risposta private specifica uno o più nomi di campo, questo requisito è limitato ai valori di campo associati ai campi di intestazione di risposta elencati. Cioè, una cache condivisa NON DEVE (MUST NOT) memorizzare i nomi di campo specificati, mentre PUÒ (MAY) memorizzare il resto del messaggio di risposta.
Nota: Questa direttiva non è un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, le cache malevole o compromesse potrebbero non riconoscere o obbedire a questa direttiva, e le reti di comunicazione potrebbero essere vulnerabili alle intercettazioni.
5.2.2.7. proxy-revalidate
La direttiva di risposta "proxy-revalidate" ha lo stesso significato della direttiva di risposta must-revalidate, tranne per il fatto che non si applica alle cache private.
5.2.2.8. max-age
Argomento: delta-seconds
La direttiva di risposta "max-age" indica che la risposta deve essere considerata obsoleta dopo che la sua età è maggiore del numero di secondi specificato.
Questa direttiva utilizza la forma token della sintassi dell'argomento: ad esempio, 'max-age=5' non 'max-age="5"'. Un mittente NON DOVREBBE (SHOULD NOT) generare la forma di stringa tra virgolette.
5.2.2.9. s-maxage
Argomento: delta-seconds
La direttiva di risposta "s-maxage" indica che, nelle cache condivise, l'età massima specificata da questa direttiva sovrascrive l'età massima specificata sia dalla direttiva max-age che dal campo di intestazione Expires. La direttiva s-maxage implica anche la semantica della direttiva di risposta proxy-revalidate.
Questa direttiva utilizza la forma token della sintassi dell'argomento: ad esempio, 's-maxage=10' non 's-maxage="10"'. Un mittente NON DOVREBBE (SHOULD NOT) generare la forma di stringa tra virgolette.
📝 翻译说明 (Translation Notes)
- 5.2.2核心响应指令: 这九个指令是HTTP缓存服务器端控制的完整体系
- must-revalidate: 金融级可靠性要求在所有语言中都得到了强调，包括504响应的强制规定
- no-cache vs no-store: 两者在所有语言中都明确区分了验证要求和存储禁止
- no-cache可选字段名: 字段级缓存控制的复杂性在所有语言版本中得到了准确传达
- public vs private: 共享/私有缓存的区别在所有语言中保持了法律级精确性
- proxy-revalidate vs must-revalidate: 对私有缓存的豁免在所有语言版本中得到了清晰说明
- s-maxage: 共享缓存优先级和隐含proxy-revalidate的规则在所有语言中准确翻译
- 隐私警告: 所有涉及隐私的指令（no-store、private）都在所有语言版本中包含了"不是可靠机制"的警告
- HTTP/1.0兼容性: no-cache的历史兼容性问题在所有语言版本中得到了准确说明