should check .bzr/ exists before posting to .bzr/smart

Bug #506196 reported by Chris Morgan on 2010-01-12
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Unassigned

Bug Description

Following the instructions at http://docs.djangoproject.com/en/dev/topics/install/#installing-development-version I tried to check out (or branch) the Django repository with bzr-svn.
It provides:
  svn co http://code.djangoproject.com/svn/django/trunk/ django-trunk
(This works.)
I ran:
  bzr co http://code.djangoproject.com/svn/django/trunk/ django-trunk
I received two HTTP authentication prompts which I left empty. SVN didn't ask for these.
  HTTP code.djangoproject.com, Realm: 'Django SVN repository' username:
  HTTP @code.djangoproject.com, Realm: 'Django SVN repository' password:
Then it said:
  bzr: ERROR: Not a branch: "http://code.djangoproject.com/svn/django/trunk/".
This is not true :-)

Synaptic reports that I have bzr 2.0.0-0ubuntu1 and bzr-svn 1.0.0~bzr3160-1.

Chris Morgan (chris.morgan) wrote :

spiv suggested in IRC to add svn+ to the start of the URL. This worked.

So: `bzr co http://code.djangoproject.com/svn/django/trunk/ django-trunk` doesn't work
But: `bzr co svn+http://code.djangoproject.com/svn/django/trunk/ django-trunk` does work

Jelmer Vernooij (jelmer) wrote :

This is triggered by bzr probing for a smart server - the POST request makes djangoproject.com reply with a 401, which causes the prompt.

affects: bzr-svn → bzr

2010/1/12 Jelmer Vernooij <email address hidden>:
> This is triggered by bzr probing for a smart server - the POST request
> makes djangoproject.com reply with a 401, which causes the prompt.

I wonder what we should do about that? The server is saying "you can
use bzr if you authenticate" so it's reasonable for us to ask the user
to authenticate.

Perhaps we should give a message "server requested authentication for
$url: $auth_domain"

But really if the server's kind-of offering bzr+http, perhaps the user
needs to specify the svn scheme.

Perhaps we should try "HEAD .bzr" before posting?

--
Martin <http://launchpad.net/~mbp/>

On Tue, 2010-01-12 at 02:26 +0000, Martin Pool wrote:
> 2010/1/12 Jelmer Vernooij <email address hidden>:
> > This is triggered by bzr probing for a smart server - the POST request
> > makes djangoproject.com reply with a 401, which causes the prompt.
>
> I wonder what we should do about that? The server is saying "you can
> use bzr if you authenticate" so it's reasonable for us to ask the user
> to authenticate.
>
> Perhaps we should give a message "server requested authentication for
> $url: $auth_domain"
>
> But really if the server's kind-of offering bzr+http, perhaps the user
> needs to specify the svn scheme.
>
> Perhaps we should try "HEAD .bzr" before posting?
GET .bzr/format before the POST should work around this I think. That
avoids an extra HTTP request.

Cheers,

Jelmer

2010/1/12 Jelmer Vernooij <email address hidden>:
>> Perhaps we should try "HEAD .bzr" before posting?
> GET .bzr/format before the POST should work around this I think. That
> avoids an extra HTTP request.

That might have helped with some cases on Google code too. So is that
going to be the point of this bug: that we should try to read from
.bzr/ or .bzr/format before trying to post to it?

...Actually I'm not sure if I understand your comment. You're saying
if we do see a .bzr/format then we should take the format name from
that, then try using rpc? It could work, though it may be a bit
strange inside bzrlib to switch to a RemoteBzrDir after we've started.

--
Martin <http://launchpad.net/~mbp/>

On Tue, 2010-01-12 at 04:39 +0000, Martin Pool wrote:
> 2010/1/12 Jelmer Vernooij <email address hidden>:
> >> Perhaps we should try "HEAD .bzr" before posting?
> > GET .bzr/format before the POST should work around this I think. That
> > avoids an extra HTTP request.
>
> That might have helped with some cases on Google code too. So is that
> going to be the point of this bug: that we should try to read from
> .bzr/ or .bzr/format before trying to post to it?
>
> ...Actually I'm not sure if I understand your comment. You're saying
> if we do see a .bzr/format then we should take the format name from
> that, then try using rpc? It could work, though it may be a bit
> strange inside bzrlib to switch to a RemoteBzrDir after we've started.
Yeah, if there is no .bzr/format file then it makes no sense to do a
POST request I think. I'm not very familiar with the smart client, so
I'm not sure how feasible this is.

Cheers,

Jelmer

Andrew Bennetts (spiv) wrote :

Jelmer Vernooij wrote:
[...]
> Yeah, if there is no .bzr/format file then it makes no sense to do a
> POST request I think. I'm not very familiar with the smart client, so
> I'm not sure how feasible this is.

Well, POST to .bzr/smart can work when there's no .bzr/branch-format in
some cases, so I'm not sure that's right. e.g. consider something like
'bzr log $branch_url/README'. That said it's probably reasonable in
principle to try GET .bzr/branch-format before POST .bzr/smart, but I
fear it'll be pretty awkward in the existing code :/

2010/1/12 Andrew Bennetts <email address hidden>:
> Jelmer Vernooij wrote:
> [...]
>> Yeah, if there is no .bzr/format file then it makes no sense to do a
>> POST request I think. I'm not very familiar with the smart client, so
>> I'm not sure how feasible this is.
>
> Well, POST to .bzr/smart can work when there's no .bzr/branch-format in
> some cases, so I'm not sure that's right.  e.g. consider something like
> 'bzr log $branch_url/README'.  That said it's probably reasonable in
> principle to try GET .bzr/branch-format before POST .bzr/smart, but I
> fear it'll be pretty awkward in the existing code :/

I think a probe for .bzr should not hurt much, and should work with
any plausible server setup, and should fit in reasonably easily. It's
true it's an unnecessary roundtrip, but there's probably more
important fat we could trim.
--
Martin <http://launchpad.net/~mbp/>

Changed in bzr:
status: New → Confirmed
importance: Undecided → Medium
summary: - SVN checkout failing with empty authentication details
+ should check .bzr/ exists before posting to .bzr/smart
tags: added: hpss http

On Tue, 2010-01-12 at 06:17 +0000, Martin Pool wrote:
> 2010/1/12 Andrew Bennetts <email address hidden>:
> > Jelmer Vernooij wrote:
> > [...]
> >> Yeah, if there is no .bzr/format file then it makes no sense to do a
> >> POST request I think. I'm not very familiar with the smart client, so
> >> I'm not sure how feasible this is.
> >
> > Well, POST to .bzr/smart can work when there's no .bzr/branch-format in
> > some cases, so I'm not sure that's right. e.g. consider something like
> > 'bzr log $branch_url/README'. That said it's probably reasonable in
> > principle to try GET .bzr/branch-format before POST .bzr/smart, but I
> > fear it'll be pretty awkward in the existing code :/
>
> I think a probe for .bzr should not hurt much, and should work with
> any plausible server setup, and should fit in reasonably easily. It's
> true it's an unnecessary roundtrip, but there's probably more
> important fat we could trim.

On particularly locked down servers, checking for .bzr will fail when a
post to .bzr/smart works : we've encountered this in the past. Skipping
the .bzr probe isn't a performance thing per se: its correctness.

-Rob

2010/1/12 Robert Collins <email address hidden>:
> On particularly locked down servers, checking for .bzr will fail when a
> post to .bzr/smart works : we've encountered this in the past. Skipping
> the .bzr probe isn't a performance thing per se: its correctness.

We do have to be pragmatic here and deal with quirky servers. On the
other hand if someone has specifically configured the server to deny a
directory but allow URLs within it that is getting pretty weird.
Perhaps no more weird than the original report on this svn server.

I can believe someone having the server set up to deny *listing* the
directory but that should be distinct.

--
Martin <http://launchpad.net/~mbp/>

Jelmer Vernooij (jelmer) on 2017-11-09
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers