Bug 422: RFC 2616 Date header requirements

The Date: header appears to already be implemented on all generated
pages and ICAP processed pages.
This tests and enforces Date: on all other outgoing replies as required.

I'm not certain this is the right place, it appears to be post-caching.
The RFC indicates the Date: should be enforced pre-caching. But was
unable to find a place of input cloning/processing after initial parse.
The storeEntry timestamp is used to estimate correct receiving date.

diff --git a/src/client_side_reply.cc b/src/client_side_reply.cc
index e61e14a2c4cee968559b7ffac6bc39d364dad332..e75c349aaba0d9ae9b5aa03cc9078984cfdd76c7 100644 (file)
--- a/src/client_side_reply.cc
+++ b/src/client_side_reply.cc
@@ -86,8 +86,9 @@ clientReplyContext::~clientReplyContext()
 clientReplyContext::clientReplyContext(ClientHttpRequest *clientContext) : http (cbdataReference(clientContext)), old_entry (NULL), old_sc(NULL), deleting(false)
 {}
 
-/* create an error in the store awaiting the client side to read it. */
-/* This may be better placed in the clientStream logic, but it has not been
+/** Create an error in the store awaiting the client side to read it.
+ *
+ * This may be better placed in the clientStream logic, but it has not been
  * relocated there yet
  */
 void
@@ -1199,10 +1200,12 @@ clientReplyContext::alwaysAllowResponse(http_status sline) const
     return result;
 }
 
-/*
- * filters out unwanted entries from original reply header
- * adds extra entries if we have more info than origin server
- * adds Squid specific entries
+/**
+ * Generate the reply headers sent to client.
+ *
+ * Filters out unwanted entries and hop-by-hop from original reply header
+ * then adds extra entries if we have more info than origin server
+ * then adds Squid specific entries
  */
 void
 clientReplyContext::buildReplyHeader()
@@ -1228,6 +1231,7 @@ clientReplyContext::buildReplyHeader()
 
     //    if (request->range)
     //      clientBuildRangeHeader(http, reply);
+
     /*
      * Add a estimated Age header on cache hits.
      */
@@ -1249,11 +1253,14 @@ clientReplyContext::buildReplyHeader()
          * the objects age, so a Age: 0 header does not add any useful
          * information to the reply in any case.
          */
-
+#if DEAD_CODE
+        // XXX: realy useless? or is there a bug now that this is detatched from the below if-sequence ?
+        // looks like this pre-if was supposed to be the browser workaround...
         if (NULL == http->storeEntry())
             (void) 0;
         else if (http->storeEntry()->timestamp < 0)
             (void) 0;
+#endif
 
         if (EBIT_TEST(http->storeEntry()->flags, ENTRY_SPECIAL)) {
             hdr->delById(HDR_DATE);
@@ -1278,7 +1285,20 @@ clientReplyContext::buildReplyHeader()
                 hdr->putStr(HDR_WARNING, tempbuf);
             }
         }
+    }
 
+    /* RFC 2616: Section 14.18
+     *
+     * Add a Date: header if missing.
+     * We have access to a clock therefore are required to amend any shortcoming in servers.
+     *
+     * NP: done after Age: to prevent ENTRY_SPECIAL double-handling this header.
+     */
+    if ( !hdr->has(HDR_DATE) ) {
+        if (http->storeEntry())
+            hdr->insertTime(HDR_DATE, http->storeEntry()->timestamp);
+        else
+            hdr->insertTime(HDR_DATE, squid_curtime);
     }
 
     /* Filter unproxyable authentication types */