[PATCH 3 of 4 V2] serve: make the URL the same for `hg serve` and `hg serve -S`

Tue Feb 21 09:32:50 EST 2017

On Mon, 20 Feb 2017 22:25:21 -0500, Matt Harbison wrote:
> On Mon, 20 Feb 2017 09:38:13 -0500, Yuya Nishihara <yuya at tcha.org> wrote:
> > On Thu, 16 Feb 2017 16:41:10 -0500, Matt Harbison wrote:
> >> # HG changeset patch
> >> # User Matt Harbison <matt_harbison at 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.