[PATCH 4 of 6] hgweb: introduce staticimmutable web command

Yuya Nishihara yuya at tcha.org
Wed Apr 5 11:43:10 EDT 2017


On Thu, 6 Apr 2017 00:33:23 +0900, Yuya Nishihara wrote:
> On Sat, 01 Apr 2017 00:29:08 -0700, Gregory Szorc wrote:
> > # HG changeset patch
> > # User Gregory Szorc <gregory.szorc at gmail.com>
> > # Date 1491021501 25200
> > #      Fri Mar 31 21:38:21 2017 -0700
> > # Node ID 0b8be3d244585f5a2874821418fce41bf7631f6c
> > # Parent  4cec8e88d09775ee6478e307e9dde94af5b9fcfd
> > hgweb: introduce staticimmutable web command

> > One trick is to use "immutable" URLs. Essentially, the content at
> > a URL is constant for the lifetime of the URL. When this URL is
> > served, the HTTP response basically says "cache me forever." There's
> > no conditional HTTP request on next access: if the client has that
> > URL cached, it just uses it no questions asked. This avoids the
> > network round trip and can result in drastically faster page loads.
> > 
> > This commit introduces a new web command for processing requests
> > for "immutable" static assets. Where the URL path pattern for a
> > "static" web command is simply <path>, the URL path pattern for a
> > "staticimmutable" web command is "<hash>/<path>" where <hash> is
> > derived from content. This makes <hash> a "strong" validator in the
> > HTTP RFC sense and allows us to leverage aggressive caching
> > techniques. Strictly speaking, the order in the URL violates
> > REST best practices: ideally <hash> would come after <path>.
> > However, a lot of tools (including browser devtools) use the
> > final path component to label a resource. A hash is not a useful
> > label. So, we invert the order so the final URL path component
> > is friendly. This makes no difference to caching behavior. But it
> > will upset REST zealots in their ivory towers. To them, I saw
> > practically wins over purity.
> 
> If I understand your proposal, a common trick is to append "?<hash>" to
> the URL so we can still offload static contents to the frontend server.

Never mind. /<hash>/<path> can be mapped by regexp location, and there might
be a browser that ignores cache-control headers if ?query string exists.

> Can't we compute the <hash> from Mercurial version (and maybe some config
> values)?


More information about the Mercurial-devel mailing list