The default Cache-Control header now becomes "no-cache". When the
--expiry option is used, it only applies to HTTP 200 responses. There is
a new --expiry404 option dessigned to allow for a short caching period
of invalid paths, but allowing regular re-checking in case the asset
becomes avaoilable in the future.
During the 1.3.1 update, a change was made to stop using http.Handle (and ServeMux
underneath), in order to have manual control over the http.Server object.
Unfortunately, it was overlooked that nothing was doing routing / multiplexing, so
when using multiple packfiles only one handler (picked arbitrarily due to map)
would actually be active on any given invocation.
Correct this by adding an explicit handler. We don't use ServeMux so as to avoid
bringing in any of its more complex behaviours like path cleaning etc.
This option allows a configurable delay after receiving SIGTERM (or
SIGINT) but before the HTTP server stops accepting new connections. It
is quite useful for distributed systems where callers are only notified
asynchronously (e.g. via service discovery) that a service is being shut
down; it prevents the shut down from occurring prior to callers
processing the notification.
This required some minor refactoring to allow the Shutdown() method on
http.Server to be accessed.
Rather than setting "Cache-Control: no-store", use "no-cache". The
difference is that "no-store" tells the browser that it must always
completely re-fetch the resource; whereas "no-cache" means that the
browser can write the resource to disk but must re-validate it (e.g.
using Etags) before re-using it.
