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.sz...@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)? _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel