clone from URL

[Paul Boddie]

On 15/06/11 09:36, norricorp wrote:
> When I connect via a browser, I get the following in the apache access_log.
> (i have removed dates to make it shorter)
> "GET /hg/p1 HTTP/1.1" 401 470 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64;
> rv:2.0.1) Gecko/20100101 Firefox/4.0.1"

This is a "not authorised" response, and your browser probably remembers 
the credentials at this point and tries again.

> "GET /hg/p1 HTTP/1.1" 304 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64;
> rv:2.0.1) Gecko/20100101 Firefox/4.0.1"
> "GET /hg/static/style-paper.css HTTP/1.1" 304 - "http://jazz/hg/p1"
> "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1"
> "GET /hg/static/hglogo.png HTTP/1.1" 304 - "http://jazz/hg/p1" "Mozilla/5.0
> (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1"
>
> Nothing in the error log.

Right, so the browser doesn't have a problem here at all.

> When I run a clone from the command line of a PC
> C:\mercurial>hg clone http://jazz/hg/p1 p1_clone
> http authorization required
> realm: Mercurial repositories
> user: jnorris
> password:
> abort: HTTP Error 404: Not Found
>
> Nothing in the access_log or error_log of apache. Which is different to
> yesterday but I have rebooted since then.

That's very strange. Mercurial (on the client) doesn't know that 
authorisation is needed, so it has to get a response from something, and 
I would expect Apache to at least log that (as it does above for the 
browser).

> Here are the changes made to the httpd.conf
> ScriptAlias /hg "/var/www/cgi-bin/hgweb.cgi"
>
> <Location /hg>
>      AuthType Basic
>      AuthName "Mercurial repositories"
>      AuthUserFile /merc_repos/hgusers
>      Require valid-user
> </Location>

I can't see a problem with this. And since the realm text matches that 
returned by "hg clone", Apache must surely be responding to such requests.

> here is the hgrc file in the .hg dir of the repsoitory
> [web]
> allow_push = jnorris, vobadm

Technically, this is superfluous for cloning, but it should also be 
acceptable.

> Here is the hgweb.cgi file
> # Path to repo or hgweb config to serve (see 'hg help hgweb')
> config = "/merc_repos/project1"
>
> # Uncomment and adjust if Mercurial is not installed system-wide:
> import sys; sys.path.insert(0, "/usr/local/lib/python2.4/site-packages")
>
> # Uncomment to send python tracebacks to the browser if an error occurs:
> import cgitb; cgitb.enable()
>
> from mercurial import demandimport; demandimport.enable()
> from mercurial.hgweb import hgweb, wsgicgi
> application = hgweb(config)
> wsgicgi.launch(application)

One thing that looks wrong here is the config setting. Since you provide 
a config file, the config setting should refer to that config file, not 
to the repository.

> and the hgweb.config file
> [paths]
> p1 = /merc_repos/project1

This config file looks good, however.

> I have made the repository writable by anyone (though in real life should be
> owned by apache rather than me I guess).

You could make it writable by Apache in various ways. ACLs can be useful 
on filesystems that support them.

> If I run hg clone http://jazz/hg/p2 p1_clone (and p2 does not exist) the I
> get the same ie authentication request and finally 404 error. The 404 error
> is sensible. And I guess the authentication is because it is running
> hgweb.cgi.

Yes.

> So I am not sure is providing the 404 error. Apache can find the files when
> requested from a browser but can not find the files when the request comes
> from hg clone.

But Apache must be logging those requests. Yesterday, you provided some 
log lines from a clone request. Are you sure they aren't being produced 
any more? Taking a look at the ones you provided already, it looks like 
authentication/authorisation occurs (after a 401 "not authorised" 
response) and then 404 "not found" is returned.

Maybe that config setting is the problem. I haven't looked to see how 
hgweb handles stray repository names on the end of URLs when it is 
configured to serve a repository directly, but I suppose it's not 
impossible that the Web interface handles it whilst the "protocol" 
interface doesn't.

Paul