Comment 3 for bug 262366

To try and describe it a different way.

If you use "bzr+http://" you get a RemoteHTTPTransport.
And then all plain Transport (VFS) requests (get() get_bytes(), etc) end up going through the bzr protocol's VFS layer. So:

t = get_transport('bzr+http://host/path/to/url')
t.get_bytes('.bzr/branch-format')

Does a POST to http://host/path/to/url/.bzr/smart with a "get\x01.bzr/branch-format" request.

On the other hand if you use "http://" you get a HTTPTransport, which will use POST for smart server verbs, but will use plain HTTP GET for any Transport requests. So doing:

t = get_transport('http://host/path/to/url')
t.get_bytes('.bzr/branch-format')

Will generate an HTTP GET /path/to/url/.bzr/branch-format

There is an open question as to which is "better" at the moment. Specifically, if you make plain HTTP GET requests, then intermediate caching proxies are able to cache appropriately. While they could not cache the output of HTTP POST requests.

The other reason is that doing a plain HTTPTransport.get_bytes() has less CPU overhead. Because we don't have to marshal and unmarshal an HPSS request and response.

It should also be noted that as we move away from using the VFS layer for Remote* objects, the different between them will decrease.

I think the basic oddity is that "bzr+http://" returns a RemoteHTTPTransport while "http://" returns a HTTPTransport, and both are able to handle the FS requests. It would seem like we would want to standardize on one method or another. Not have both. Though in awilkins' case, it does allow him to use bzr+http:// for IIS6 support.