Maintaining last-modified dates on delivery of Archival materials from a repository

Mozilla-Last-Modified-Thread.txt

https://bugzilla.mozilla.org/show_bug.cgi?id=178506 

Bug 178506 - save original last-modified date on file downloads

Resolved: WontFix

Reported:	2002-11-05 12:09 PST

--

Original thread: https://github.com/SaltwaterC/http-request/issues/6 

--

Golang change date... 

https://www.socketloop.com/tutorials/golang-change-a-file-last-modified-date-and-time

rfc7232-extract.txt

https://tools.ietf.org/html/rfc7232#section-2.2

Fielding & Reschke           Standards Track                    [Page 7]
 
RFC 7232              HTTP/1.1 Conditional Requests            June 2014

2.2.  Last-Modified

   The "Last-Modified" header field in a response provides a timestamp
   indicating the date and time at which the origin server believes the
   selected representation was last modified, as determined at the
   conclusion of handling the request.

     Last-Modified = HTTP-date

   An example of its use is

     Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

2.2.1.  Generation

   An origin server SHOULD send Last-Modified for any selected
   representation for which a last modification date can be reasonably
   and consistently determined, since its use in conditional requests
   and evaluating cache freshness ([RFC7234]) results in a substantial
   reduction of HTTP traffic on the Internet and can be a significant
   factor in improving service scalability and reliability.

   A representation is typically the sum of many parts behind the
   resource interface.  The last-modified time would usually be the most
   recent time that any of those parts were changed.  How that value is
   determined for any given resource is an implementation detail beyond
   the scope of this specification.  What matters to HTTP is how
   recipients of the Last-Modified header field can use its value to
   make conditional requests and test the validity of locally cached
   responses.

   An origin server SHOULD obtain the Last-Modified value of the
   representation as close as possible to the time that it generates the
   Date field value for its response.  This allows a recipient to make
   an accurate assessment of the representation's modification time,
   especially if the representation changes near the time that the
   response is generated.

   An origin server with a clock MUST NOT send a Last-Modified date that
   is later than the server's time of message origination (Date).  If
   the last modification time is derived from implementation-specific

   metadata that evaluates to some time in the future, according to the
   origin server's clock, then the origin server MUST replace that value
   with the message origination date.  This prevents a future
   modification date from having an adverse impact on cache validation.

   An origin server without a clock MUST NOT assign Last-Modified values
   to a response unless these values were associated with the resource
   by some other system or user with a reliable clock.

2.2.2.  Comparison

   A Last-Modified time, when used as a validator in a request, is
   implicitly weak unless it is possible to deduce that it is strong,
   using the following rules:

   o  The validator is being compared by an origin server to the actual
      current validator for the representation and,

   o  That origin server reliably knows that the associated
      representation did not change twice during the second covered by
      the presented validator.

   or

   o  The validator is about to be used by a client in an
      If-Modified-Since, If-Unmodified-Since, or If-Range header field,
      because the client has a cache entry for the associated
      representation, and

   o  That cache entry includes a Date value, which gives the time when
      the origin server sent the original response, and

   o  The presented Last-Modified time is at least 60 seconds before the
      Date value.

   or

   o  The validator is being compared by an intermediate cache to the
      validator stored in its cache entry for the representation, and

   o  That cache entry includes a Date value, which gives the time when
      the origin server sent the original response, and

   o  The presented Last-Modified time is at least 60 seconds before the
      Date value.

   This method relies on the fact that if two different responses were
   sent by the origin server during the same second, but both had the
   same Last-Modified time, then at least one of those responses would
   have a Date value equal to its Last-Modified time.  The arbitrary
   60-second limit guards against the possibility that the Date and
   Last-Modified values are generated from different clocks or at
   somewhat different times during the preparation of the response.  An
   implementation MAY use a value larger than 60 seconds, if it is
   believed that 60 seconds is too short.

rosetta-example-header-txt

GET /delivery/StreamGate?is_rtl=false&is_mobile=false&dps_dvs=1443578919337~850&dps_pid=FL25316124 HTTP/1.1
Host: ndhadeliver.natlib.govt.nz
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: visid_incap_234913=RzCXkx4EQn6ezlMutKAuLDe+yVUAAAAAQUIPAAAAAACIMMKRUy7B9oqtudCs7JY0; NDHASLB03=henga; incap_ses_248_234913=b8AGJmitmDb2fxf3TRNxAy+t+FUAAAAAAxZQ/bsnUiJHMslwGQ58JQ==; __utma=141778221.611758676.1442896782.1442896782.1442896782.1; __utmc=141778221; __utmz=141778221.1442896782.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); PDS_HANDLE=299201519323339842242274750346758; JSESSIONID=EB69A5288CC09D8F66108EA76AE8029C.henga.natlib.govt.nz:1801
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-control: must-revalidate
Connection: Keep-Alive
Content-Description: File Transfert
Content-Disposition: inline;filename="draft PM notes.doc"
Content-Length: 72704
Content-Transfer-Encoding: binary
Content-Type: application/msword;charset=UTF-8
Date: Wed, 30 Sep 2015 02:18:15 GMT
Expires: 0
Keep-Alive: timeout=5, max=100
Server: