C'è un solo campo per la data nell'intestazione.Se manca il destinatario ne aggiunge uno.Torna da link
14.18 Data
Il campo dell'intestazione generale della data rappresenta la data e l'ora in cui il messaggio è stato originato, con la stessa semantica dell'origine in RFC 822. Il valore del campo è una data HTTP, come descritto nella sezione 3.3.1; DEVE essere inviato nel formato di RFC 1123 [8].
Date="Date" ":" HTTP-date
Un esempio è
Data: martedì 15 novembre 1994 08:12:31 GMT
I server di origine DEVONO includere un campo di intestazione Data in tutte le risposte, tranne in questi casi:
- Se il codice di stato della risposta è 100 (Continua) o 101 (Protocolli di commutazione), la risposta MAGGIO include un campo di intestazione Data, a scelta del server. 2. Se il codice di stato della risposta trasmette un errore del server, ad es. 500 (Errore interno server) o 503 (Servizio non disponibile), ed è scomodo o impossibile generare una Data valida. 3. Se il server non ha un orologio che può fornire un'approssimazione ragionevole dell'ora corrente, le sue risposte NON DEVONO includere un campo di intestazione Data. In questo caso, DEVONO essere seguite le regole nella sezione 14.18.1.
Un messaggio ricevuto che non ha un campo di intestazione Data DEVE essere assegnato a uno dal destinatario se il messaggio verrà memorizzato nella cache da quel destinatario o gateway tramite un protocollo che richiede una Data. Un'implementazione HTTP senza orologio NON DEVE memorizzare le risposte nella cache senza riconvalidarle su ogni utilizzo. Una cache HTTP, in particolare una cache condivisa, DOVREBBE usare un meccanismo, come NTP [28], per sincronizzare il suo orologio con uno standard esterno affidabile.
I client DEVONO inviare solo un campo dell'intestazione Data nei messaggi che includono un corpo dell'entità, come nel caso delle richieste PUT e POST, e anche in questo caso è facoltativo. Un client senza orologio NON DEVE inviare un campo di intestazione Data in una richiesta.
La data HTTP inviata in un'intestazione Data NON DEVE rappresentare una data e un'ora successive alla generazione del messaggio. DOVREBBE rappresentare la migliore approssimazione disponibile della data e dell'ora di generazione del messaggio, a meno che l'implementazione non sia in grado di generare una data e un'ora ragionevolmente precise. In teoria, la data dovrebbe rappresentare il momento immediatamente prima che l'entità sia generata. In pratica, la data può essere generata in qualsiasi momento durante l'origine del messaggio senza influire sul suo valore semantico.