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

Gregory Szorc gregory.szorc at gmail.com
Mon Apr 3 21:25:04 EDT 2017


On Mon, Apr 3, 2017 at 6:13 PM, Matt Harbison <mharbison72 at gmail.com> wrote:

> On Sat, 01 Apr 2017 03:29:08 -0400, Gregory Szorc <gregory.szorc at gmail.com>
> 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
>>
>
> Should these caching related patches be sensitive to '--config
> web.cache=False'?  I can't imagine why you wouldn't want to cache in a
> production environment.  It has been useful for development testing, but
> it's not documented as experimental/developer only.
>

Good question.

Since immutable content is, well, immutable, caching is like an intrinsic
property that follows from being immutable. So I can make the argument that
Cache-Control for those URLs should always be emitted.

What we could do is have the templating layer respect web.cache. e.g. if
web.cache=false, the template filter for resolving the URL/path would emit
/static/<path> instead of /staticimmutable/...

Also, with a little work, we could likely improve the web caching to the
point it is useful in a dev environment too. The caching strategy today
uses the repo mtime for cache invalidation. Since template files are
independent of repositories, this caching strategy is just plain wrong. We
need to take the actual template source files into consideration when
checking cache validity. We're lucky more people aren't complaining about
this bug. Come to think of it, this is likely responsible for some weird
behavior I've seen on hg.mozilla.org over the years! So maybe I'll just fix
it...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170403/b17cc693/attachment.html>


More information about the Mercurial-devel mailing list