Passa al contenuto principale

6. Liste Cronologiche (History Lists)

Gli user agent hanno spesso meccanismi di cronologia, come pulsanti "Indietro" e liste cronologiche, che possono essere utilizzati per visualizzare nuovamente una rappresentazione recuperata in precedenza in una sessione.

Il modello di freschezza (Sezione 4.2) non si applica necessariamente ai meccanismi di cronologia. Cioè, un meccanismo di cronologia può visualizzare una rappresentazione precedente anche se è scaduta.

Ciò non impedisce al meccanismo di cronologia di informare l'utente che una vista potrebbe essere obsoleta o di rispettare le direttive di cache (ad es., Cache-Control: no-store).

7. Considerazioni IANA (IANA Considerations)

7.1. Registro delle Direttive di Cache (Cache Directive Registry)​

Il "Registro delle Direttive di Cache del Protocollo di Trasferimento Ipertestuale (HTTP)" definisce lo spazio dei nomi per le direttive di cache. È stato creato ed è ora mantenuto su http://www.iana.org/assignments/http-cache-directives.

7.1.1. Procedura (Procedure)​

Una registrazione DEVE includere i seguenti campi:

  • Nome della Direttiva di Cache (Cache Directive Name)
  • Puntatore al testo di specifica (Pointer to specification text)

I valori da aggiungere a questo spazio dei nomi richiedono la revisione IETF (vedere [RFC5226], Sezione 4.1).

7.1.2. Considerazioni per Nuove Direttive di Controllo Cache (Considerations for New Cache Control Directives)​

Le nuove direttive di estensione dovrebbero considerare di definire:

  • Cosa significa che una direttiva venga specificata più volte,
  • Quando la direttiva non accetta un argomento, cosa significa quando un argomento è presente,
  • Quando la direttiva richiede un argomento, cosa significa quando manca,
  • Se la direttiva è specifica per le richieste, le risposte o può essere utilizzata in entrambe.

Vedere anche Sezione 5.2.3.

7.1.3. Registrazioni (Registrations)​

Il registro è stato popolato con le seguenti registrazioni:

Direttiva di Cache (Cache Directive)Riferimento (Reference)
max-ageSezione 5.2.1.1, Sezione 5.2.2.8
max-staleSezione 5.2.1.2
min-freshSezione 5.2.1.3
must-revalidateSezione 5.2.2.1
no-cacheSezione 5.2.1.4, Sezione 5.2.2.2
no-storeSezione 5.2.1.5, Sezione 5.2.2.3
no-transformSezione 5.2.1.6, Sezione 5.2.2.4
only-if-cachedSezione 5.2.1.7
privateSezione 5.2.2.6
proxy-revalidateSezione 5.2.2.7
publicSezione 5.2.2.5
s-maxageSezione 5.2.2.9
stale-if-error[RFC5861], Sezione 4
stale-while-revalidate[RFC5861], Sezione 3

7.2. Registro dei Codici di Avviso (Warn Code Registry)​

Il "Registro dei Codici di Avviso del Protocollo di Trasferimento Ipertestuale (HTTP)" definisce lo spazio dei nomi per i codici di avviso. È stato creato ed è ora mantenuto su http://www.iana.org/assignments/http-warn-codes.

7.2.1. Procedura (Procedure)​

Una registrazione DEVE includere i seguenti campi:

  • Codice di Avviso (3 cifre) (Warn Code (3 digits))
  • Descrizione Breve (Short Description)
  • Puntatore al testo di specifica (Pointer to specification text)

I valori da aggiungere a questo spazio dei nomi richiedono la revisione IETF (vedere [RFC5226], Sezione 4.1).

7.2.2. Registrazioni (Registrations)​

Il registro è stato popolato con le seguenti registrazioni:

Codice di Avviso (Warn Code)Descrizione Breve (Short Description)Riferimento (Reference)
110La Risposta è Obsoleta (Response is Stale)Sezione 5.5.1
111Revalidazione Fallita (Revalidation Failed)Sezione 5.5.2
112Operazione Disconnessa (Disconnected Operation)Sezione 5.5.3
113Scadenza Euristica (Heuristic Expiration)Sezione 5.5.4
199Avviso Vario (Miscellaneous Warning)Sezione 5.5.5
214Trasformazione Applicata (Transformation Applied)Sezione 5.5.6
299Avviso Persistente Vario (Miscellaneous Persistent Warning)Sezione 5.5.7

7.3. Registrazione del Campo di Intestazione (Header Field Registration)​

I campi di intestazione HTTP sono registrati nel registro "Message Headers" mantenuto su http://www.iana.org/assignments/message-headers/.

Questo documento definisce i seguenti campi di intestazione HTTP, quindi il registro "Permanent Message Header Field Names" è stato aggiornato di conseguenza (vedere [BCP90]).

Nome del Campo di Intestazione (Header Field Name)Protocollo (Protocol)Stato (Status)Riferimento (Reference)
AgehttpstandardSezione 5.1
Cache-ControlhttpstandardSezione 5.2
ExpireshttpstandardSezione 5.3
PragmahttpstandardSezione 5.4
WarninghttpstandardSezione 5.5

Il controllore delle modifiche è: "IETF ([email protected]) - Internet Engineering Task Force".

8. Considerazioni sulla Sicurezza (Security Considerations)

Questa sezione ha lo scopo di informare sviluppatori, fornitori di informazioni e utenti dei problemi di sicurezza noti specifici per il caching HTTP. Considerazioni sulla sicurezza più generali sono affrontate nella messaggistica HTTP [RFC7230] e nella semantica [RFC7231].

Le cache espongono vulnerabilità potenziali aggiuntive, poiché i contenuti della cache rappresentano un obiettivo attraente per lo sfruttamento malevolo. Poiché i contenuti della cache persistono dopo il completamento di una richiesta HTTP, un attacco alla cache può rivelare informazioni molto tempo dopo che un utente crede che le informazioni siano state rimosse dalla rete. Pertanto, i contenuti della cache devono essere protetti come informazioni sensibili.

In particolare, vari attacchi potrebbero essere amplificati dall'essere memorizzati in una cache condivisa; tali attacchi di "avvelenamento della cache" utilizzano la cache per distribuire un payload malevolo a molti client, e sono particolarmente efficaci quando un attaccante può utilizzare difetti di implementazione, privilegi elevati o altre tecniche per inserire tale risposta in una cache. Un vettore di attacco comune per l'avvelenamento della cache consiste nello sfruttare le differenze nell'analisi dei messaggi sui proxy e negli user agent; vedere Sezione 3.3.3 di [RFC7230] per i requisiti pertinenti.

Allo stesso modo, i difetti di implementazione (così come l'incomprensione del funzionamento della cache) potrebbero portare al caching di informazioni sensibili (ad es., credenziali di autenticazione) che si ritiene siano private, esponendole a parti non autorizzate.

Inoltre, l'uso stesso di una cache può sollevare preoccupazioni sulla privacy. Ad esempio, se due utenti condividono una cache e il primo naviga verso un sito, il secondo potrebbe essere in grado di rilevare che l'altro è stato su quel sito, perché le risorse da esso si caricano più velocemente, grazie alla cache.

Si noti che il campo di intestazione di risposta Set-Cookie [RFC6265] non inibisce il caching; una risposta cacheable con un campo di intestazione Set-Cookie può essere (e spesso è) utilizzata per soddisfare richieste successive alle cache. I server che desiderano controllare il caching di queste risposte sono incoraggiati a emettere campi di intestazione di risposta Cache-Control appropriati.

9. Ringraziamenti (Acknowledgments)

Vedere Sezione 10 di [RFC7230].

10. Riferimenti (References)

10.1. Riferimenti Normativi (Normative References)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.

  • [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

  • [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.

  • [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.

  • [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.

10.2. Riferimenti Informativi (Informative References)​

  • [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

  • [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, April 2010.

  • [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.

  • [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.

Appendice A. Modifiche da RFC 2616 (Changes from RFC 2616)

La specifica è stata sostanzialmente riscritta per chiarezza.

Le condizioni in cui una risposta autenticata può essere memorizzata in cache sono state chiarite. (Sezione 3.2)

I nuovi codici di stato possono ora definire che le cache sono autorizzate a utilizzare la freschezza euristica con essi. Le cache sono ora autorizzate a calcolare la freschezza euristica per gli URI con componenti di query. (Sezione 4.2.2)

L'algoritmo per calcolare l'età è ora meno conservativo. Le cache sono ora tenute a trattare le date con fusi orari come se fossero non valide, perché non è possibile indovinarle accuratamente. (Sezione 4.2.3)

Il campo di intestazione di risposta Content-Location non è più utilizzato per determinare la risposta appropriata da utilizzare durante la validazione. (Sezione 4.3)

L'algoritmo per selezionare una risposta negoziata memorizzata in cache da utilizzare è stato chiarito in diversi modi. In particolare, ora consente esplicitamente la canonizzazione specifica dell'intestazione durante l'elaborazione dei campi di intestazione di selezione. (Sezione 4.1)

I requisiti riguardanti l'evitamento di attacchi denial-of-service quando si esegue l'invalidazione sono stati chiariti. (Sezione 4.4)

L'invalidazione della cache si verifica solo quando viene ricevuta una risposta di successo. (Sezione 4.4)

Le direttive di cache sono esplicitamente definite come case-insensitive. La gestione di più istanze di direttive di cache quando se ne prevede solo una è ora definita. (Sezione 5.2)

La direttiva di richiesta "no-store" non si applica alle risposte; cioè, una cache può soddisfare una richiesta con no-store su di essa e non la invalida. (Sezione 5.2.1.5)

Le forme qualificate delle direttive di cache private e no-cache sono notate come non ampiamente implementate; ad esempio, "private=foo" è interpretato da molte cache come semplicemente "private". Inoltre, il significato della forma qualificata di no-cache è stato chiarito. (Sezione 5.2.2)

Il significato della direttiva di risposta "no-cache" è stato chiarito. (Sezione 5.2.2.2)

Il limite di un anno sui valori del campo di intestazione Expires è stato rimosso; invece, viene fornita la motivazione per l'utilizzo di un valore ragionevole. (Sezione 5.3)

Il campo di intestazione Pragma è ora definito solo per la retrocompatibilità; i futuri pragma sono deprecati. (Sezione 5.4)

Alcuni requisiti riguardanti la produzione e l'elaborazione dei campi di intestazione Warning sono stati rilassati, poiché non è ampiamente implementato. Inoltre, il campo di intestazione Warning non utilizza più la codifica RFC 2047, né consente più lingue, poiché questi aspetti non sono stati implementati. (Sezione 5.5)

Questa specifica introduce i registri di Direttiva di Cache e Codice di Avviso e definisce le considerazioni per nuove direttive di cache. (Sezione 7.1 e Sezione 7.2)

Appendice B. ABNF Importato (Imported ABNF)

Le seguenti regole fondamentali sono incluse per riferimento, come definito nell'Appendice B.1 di [RFC5234]: ALPHA (lettere), CR (ritorno a capo), CRLF (CR LF), CTL (controlli), DIGIT (decimale 0-9), DQUOTE (virgoletta doppia), HEXDIG (esadecimale 0-9/A-F/a-f), LF (avanzamento riga), OCTET (qualsiasi sequenza di 8 bit di dati), SP (spazio) e VCHAR (qualsiasi carattere US-ASCII visibile).

Le seguenti regole sono definite in [RFC7230]:

OWS           = <OWS, vedere [RFC7230], Sezione 3.2.3>
field-name    = <field-name, vedere [RFC7230], Sezione 3.2>
quoted-string = <quoted-string, vedere [RFC7230], Sezione 3.2.6>
token         = <token, vedere [RFC7230], Sezione 3.2.6>

port          = <port, vedere [RFC7230], Sezione 2.7>
pseudonym     = <pseudonym, vedere [RFC7230], Sezione 5.7.1>
uri-host      = <uri-host, vedere [RFC7230], Sezione 2.7>

Le seguenti regole sono definite in altre parti:

HTTP-date     = <HTTP-date, vedere [RFC7231], Sezione 7.1.1.1>

Appendice C. ABNF Raccolto (Collected ABNF)

Nell'ABNF raccolto di seguito, le regole di lista sono espanse secondo la Sezione 1.2 di [RFC7230].

Age = delta-seconds

Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
 cache-directive ] )

Expires = HTTP-date

HTTP-date = <HTTP-date, vedere [RFC7231], Sezione 7.1.1.1>

OWS = <OWS, vedere [RFC7230], Sezione 3.2.3>

Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
 pragma-directive ] )

Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
 )

cache-directive = token [ "=" ( token / quoted-string ) ]

delta-seconds = 1*DIGIT

extension-pragma = token [ "=" ( token / quoted-string ) ]

field-name = <field-name, vedere [RFC7230], Sezione 3.2>

port = <port, vedere [RFC7230], Sezione 2.7>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, vedere [RFC7230], Sezione 5.7.1>

quoted-string = <quoted-string, vedere [RFC7230], Sezione 3.2.6>

token = <token, vedere [RFC7230], Sezione 3.2.6>

uri-host = <uri-host, vedere [RFC7230], Sezione 2.7>

warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
 ]

Indirizzi degli Autori (Authors' Addresses)​

Roy T. Fielding (editore)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA

EMail: [email protected]
URI: http://roy.gbiv.com/

Mark Nottingham (editore)
Akamai

EMail: [email protected]
URI: http://www.mnot.net/

Julian F. Reschke (editore)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany

EMail: [email protected]
URI: http://greenbytes.de/tech/webdav/

Ultimo aggiornamento il