PathNotChild: Path "http://url" is not a child of path "http://jakob@url": user name mismatch

[Jakob]

This bug may be related to bug #245964.
When I try to access a bzr-repository over http that is protected by a user/password combo through the .htaccess file and gets redirected to another address I get the following problem:

PathNotChild: Path "http://path_to_repo/.bzr/smart" is not a child of path "http://jakob@path_to_repo/": user name mismatch

I tracked this particular problem down to the call to the following line in BzrDir.open_from_transport.redirected()
   relpath = transport.relpath(qualified_source) (this is the member of the ConnectedTransport class)
The problem is that the qualified_source which comes from the errors.RedirectRequested does NOT contain the 'user@' part, but the relpath() member of transport DOES compare the users. More concrote: in relpath() a call is performed to:
  transport._split_url(qualified_source)
This will give no user, because it is not passed along in the url, but this empty user is compared with transport._user. This actually raises the error above. The very exact problem occurs just a bit later, when a new transport is created with the target-url:
  return get_transport(target)
This target also comes from the errors.RedirectRequest instance and therefore does not hold the user/password, as also mentioned by the FIXME that accompanies this line.
The easiest way to circumvent this problem is to make sure that qualified_source and target are passed with user/password in the url. I created a patch that does this in the next message.

[Jakob (jakobsybren)]

This is a quick and dirty patch for bzrdir.py that solves at least the particular problem I had.

Still, I believe the actual problem is on a much more basic level. Different functions work with different ideas about how to deal with possible authorization-tokens in urls. Some do deal with it, some don't. The Request-class even uses a dictionary for it. I guess this is the basic problem and needs to be standardized throughout bzr. So: pass only empty urls between functions and pass auth-tokens seperately, or always pass the full url always. But not sometimes the one, than the other.
Therefore I'm not completely sure whether this patch will solve all problems with redirection, since it seems slightly specialized to deal with http-urls.

[Vincent Ladeuil (vila)]

What kind of redirection are you doing (and how) ?

Can you revert your patch and issue the command that was failing adding -Dhttp ?

Then post:
- the complete traceback you got (without your patch)
- the relevant part of your ./bzr.log file
- the relevant part of your .htacess file

That will help get a better understanding of the issues.

[Jakob (jakobsybren)]

I'm not sure how the redirection is performed. That's not really important anyway. But whenever I'm inside the local network at my institute at www.astro.rug.nl, all addresses are redirected to www.intra.astro.rug.nl, which I guess is done by apache.

So let's put in some gory details. I have reverted the patch.
I have a repos at /~jakobb/bzr_repos/repos1 and in that directory is a .htaccess file with amongst other things:

 AuthName "Bazaar repos"
 AuthType Basic
 AuthUserFile /Users/users/jakobb/.public_html/.htpasswd_bzr
 AuthGroupFile /dev/null
 require valid-user

One of the valid users is 'jakob' Now I run:
bzr co|branch http://<email address hidden>/~jakobb/bzr_repos/repos1
(any of these type of commands) and I get http://pastebin.com/f52de02d9
The main error is:
bzr: ERROR: bzrlib.errors.PathNotChild: Path "http://www.astro.rug.nl/%7Ejakobb/bzr_repos/repos1/.bzr/smart" is not a child of path "http://<email address hidden>/%7Ejakobb/bzr_repos/repos1/": user name mismatch
As I said in my original postings, this error is raised by ConnectedTransport.relpath() in transport/__init__.py because this member compares the user/password in the given path - which does NOT include the user/password anymore - with the user/password stored in the instance as self._user/self._password. The relevant part of the bzr.log file is at http://pastebin.com/f4a09eacb (I also attached a clean logfile with the same stuff)

Let me review what I already found out, with all the additional info in hand. What happens is that bzr get's a request to redirect the www.astro.rug.nl address to www.intra.astro.rug.nl in the BzrDir.open_from_transport() function, or actually inside do_catching_redirections() inside transport/__init__.py This results in the creation of an errors.RedirectRequest. This object however only gets the url of the source and target WITHOUT any user/password whatsoever (I'm not sure about the eventual port)
The exception is caught by do_catching_redirections(), which will call the redirected() function that is in BzrDir.open_from_transport(), which get's a redirection_notice (which is completely unnecessary anyway, because it doesn't do anything with it) Then this function uses the urls it gets from this RedirectRequest to do some checks. That's where things go wrong, because like I said, this instance didn't receive any info about user/passwords.
In my patch I added a little function that calls ConnectedTransport._split_url() on the now target url and ConnectedTransport._unsplit_url() to add in the user/password into the target url to get a good comparison in ConnectedTransport.relpath() AND to get the right target when the actual redirection is performed with the call of get_transport(target)

[Jakob (jakobsybren)]

By the way...... reading this, you may wonder what happens if I do:

 bzr co|branch http://<email address hidden>/~jakobb/bzr_repos/repos1

(with the pipe-symbol I obviously mean 'or': any of these commands will give precisely the same failure)
Given that things go wrong when redirection is taking place, you may suspect this will succeed. And indeed it does! I do have to type the password TWICE though????????? (Actually this is also the case with my little patch)

[Vincent Ladeuil (vila)]

Jakob, can you try the patch in the associated branch and confirm that it fixes your problem ?

There are other ways to address your particular need too (involving using an auhentication.conf file), but that fix should provide a reasonably better solution than the actual bzr.