On Mon, 20 Feb 2017 22:25:21 -0500, Matt Harbison wrote:
> On Mon, 20 Feb 2017 09:38:13 -0500, Yuya Nishihara <y...@tcha.org> wrote:
> > On Thu, 16 Feb 2017 16:41:10 -0500, Matt Harbison wrote:
> >> # HG changeset patch
> >> # User Matt Harbison <matt_harbi...@yahoo.com>
> >> # Date 1486877030 18000
> >> # Sun Feb 12 00:23:50 2017 -0500
> >> # Node ID 38babd487181374325f3d27c5bc081dadf31b9b9
> >> # Parent 27a4bc77e8b8e50abc76c387f117082e5853c47e
> >> serve: make the URL the same for `hg serve` and `hg serve -S`
> >
> >> elif not virtual:
> >> + if self._rootrepo:
> >> + # Redirect '/' to the main repo when -S is given.
> >> + path = '/' + self._rootrepo
> >> + if self.prefix:
> >> + path = '/' + self.prefix + path
> >> + req.headers.append(('Location', path))
> >> + html = '<html>Moved <a href="' + path +
> >> '">here</a>.</html>'
> >> + req.respond(HTTP_MOVED_PERMANENTLY, "text/html",
> >> body=html)
> >> + return []
> >
> > Suppose "hg serve" is used for temporarily serving random repositories,
> > 301
> > seems too strong.
>
> The temporary serve is the case that I'm interested in. It may not be
> clear from this snippet, but the redirect is only reachable when using `hg
> serve -S`, not random repos listed in a --web-conf file.
>
> I guess I didn't think it was too strong, because the repo never is at
> '/'. Once the `hg serve` process is killed, everything is gone.
> Everything goes away eventually. But until then, it's a permanent
> redirect.
>
> The temporary/permanent distinction is important, because there needs to
> be a trigger to update paths.default in hgrc without doing so for
> temporary redirects. The updated hgrc path is important, because the
> subrepo is cloned relative to the parent repo's paths.default value.
> (Keeping both the sub=sub and sub=../sub style paths working in the two
> new tests were one of the many headaches with this.)
>
> Since nothing other than hg clients should see the redirect, do you have a
> specific concern? (I haven't paid much attention to chg to know if it
> would somehow cache the URL and get directed wrong when `hg serve` is
> killed and something else is served. But the aggressive caching done by
> web browsers is why I limited the redirect as narrowly as possible.)
Hmm, if no web browser is involved, it would be okay as hg client wouldn't have
a permanent URL cache. I don't like the idea of using redirection to compensate
the problem of hgweb, though.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
