http smart server autodetection does VFS operations directly.

[John Szakmeister]

For access control, HTTP server operators would like to push all bzr content access through the smart server, but 'bzr co' and other operations may fall back to VFS from time to time. When they do, they currently make the VFS requests over plain HTTP even though a smart server is present. For consistent application of ACLs it would be better to tunnel the VFS requests via the smart server.

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Szakmeister wrote:
> Public bug reported:
>
> We've set up a smart server instance using WSGI so that we could place
> access controls on the project branches. We really like to use a
> checkout of the server's branch to make merging into the mainline
> easier. Unfortunately, 'bzr co' attempts to acces .bzr/branch/branch-
> format instead of going through the smart server. Since we don't allow
> raw access to the branches, this fails. It should really be using the
> smart server transport. Interestingly, 'bzr branch --bind' works fine.
>
> Sorry I can't give you a short way to reproduce this, but I'd be happy
> to try a patch.
>
> ** Affects: bzr
> Importance: Undecided
> Status: New
>
> ** Summary changed:

There is often a difference between:

 bzr co bzr+http://
and
 bzr co http://

Did you try both?

The former requires all requests to go through the bzr protocol, the
latter allows access to certain requests to go via standard http. (For
stuff like reading the format files, is the most obvious difference.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwWltwACgkQJdeBCYSNAAOBgACfSJwI2YgdZ5qGkLcaP4KNzw/x
fj8An0Ykj9uYiy1LHSt9lBPZ9R8cdvs6
=8NBN
-----END PGP SIGNATURE-----

[John Szakmeister (jszakmeister)]

On Mon, Jun 14, 2010 at 4:53 PM, John A Meinel <email address hidden> wrote:
[snip]
> There is often a difference between:
>
>  bzr co bzr+http://
> and
>  bzr co http://
>
> Did you try both?
>
> The former requires all requests to go through the bzr protocol, the
> latter allows access to certain requests to go via standard http. (For
> stuff like reading the format files, is the most obvious difference.)

No, I didn't. I was under the impression, from exchanges on the
mailing list, that with bzr+ that the http transport would probe for
smart server support and use it, if it was available.

I did just give bzr+https and try, and that works, but it'd be really
nice not to have to specify bzr+ every time to make this go.

-John

[Robert Collins (lifeless)]

John, a few notes:

 - bzr is not yet VFS free - the smart server protocol only expresses a subset of the operations that can take place.
 - I don't think the behaviour you're seeing is by design, we can certainly look at changing it.
 - even if changed, because we're not VFS free, you'll still get VFS requests coming into the smart server - but you could choose to disable that entirely, and we can work on making more operations VFS free.

[John Szakmeister (jszakmeister)]

On Mon, Jun 14, 2010 at 9:56 PM, Robert Collins
<email address hidden> wrote:
> John, a few notes:
>
>  - bzr is not yet VFS free - the smart server protocol only expresses a subset of the operations that can take place.

You know, I remember looking at the smart server code and thinking "it
doesn't look like everything is here", now that you mention it.

>  - I don't think the behaviour you're seeing is by design, we can certainly look at changing it.

That would be awesome. I did spend some time trying to track down the
issue. Should the code ever be calling
BzrDir.open_from_transport(self.root_transport, _server_formats=False)
when root_transport is remote?

>  - even if changed, because we're not VFS free, you'll still get VFS requests coming into the smart server - but you could choose to disable that entirely, and we can work on making more operations VFS free.

That would be great too. I'm obviously less familiar with the bzr
internals, so any tips on where to go with this would be useful.

BTW, I think bug #262366 is related to this, now that you changed the
description. :-)

-John

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> John, a few notes:
>
> - bzr is not yet VFS free - the smart server protocol only expresses a subset of the operations that can take place.
> - I don't think the behaviour you're seeing is by design, we can certainly look at changing it.
> - even if changed, because we're not VFS free, you'll still get VFS requests coming into the smart server - but you could choose to disable that entirely, and we can work on making more operations VFS free.
>
> ** Changed in: bzr
> Status: New => Confirmed
>
> ** Changed in: bzr
> Importance: Undecided => Medium
>
> ** Summary changed:
>
> - bzr co attempts to check .bzr/branch/branch-format when using a smart server
> + http smart server autodetection does VFS operations directly.
>

We discussed this a bunch back when someone opened a bug about using
bzr+http and IIS6. Basically, he couldn't configure it easily to support
mixed mode (some requests go to bzr, some go to IIS). As such, we found
that bzr+http:// works, because it uses the bzr-proto for VFS requests,
and plain http:// was mixed.

Conceptually it seemed ~ok, since you can get caching, etc for HTTP
requests, that you wouldn't get for vfs requests. I don't really mind if
we switch, though.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwXlEwACgkQJdeBCYSNAAPi8ACfXEMeehbuoFd1j9QV4N49WdDv
0VQAn0bcZRqQ8wjjERPFYDyo4wERqUtt
=Nl0I
-----END PGP SIGNATURE-----