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

Mon Feb 20 22:25:21 EST 2017

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.)