Client uses mixed mode for HTTP URIs on smart server

Bug #262366 reported by Adrian Wilkins
4
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Wishlist
Unassigned

Bug Description

bzr ls bzr+http://foo/bar

This command uses only requests terminating in .bzr/smart and is this only served by Bazaar. This works fine on IIS 7 and should also work on IIS 6

bzr ls http://foo/bzr

An HTTP HPSS server is detected, but a mixture of smart and dumb requests are used.

While this is not an issue on a "proper" web server, at present this means that attempts to access branches via plain http:// URI on IIS 6 don't work if you have configured a smart server using an ISAPI extension to field smart requests. It is currently difficult to serve both smart and dumb responses as the API for "passing" to the next handler is not supported in PyISAPIe which is the only tested and functioning WSGI support for Bazaar on IIS.

IIS7 can be configured properly because it supports wildcards for URL handlers. IIS6 only supports matching handlers for URLs ending in dotted file extensions (i.e. not .bzr/smart )

Revision history for this message
Adrian Wilkins (adrian-wilkins) wrote :
Revision history for this message
Adrian Wilkins (adrian-wilkins) wrote :
description: updated
Revision history for this message
John A Meinel (jameinel) wrote :

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.

Revision history for this message
John A Meinel (jameinel) wrote :

mostly we just want to figure out what the *desired* behavior is.

Changed in bzr:
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
Phillip Sitbon (phillip-sitbon) wrote :

Hi folks,

I'm the developer & maintainer for PyISAPIe.

I actually came across this while searching for the proper method of "passing to the next handler."

> IIS6 only supports matching handlers for URLs ending in dotted file extensions
>

This is true except when PyISAPIe is the "global" wildcard map. Would your problem be fixed if it were set to that and passed unsupported URLs back to IIS?

I'm still trying to figure out the situation and how to make this all work- any input/suggestions from actual users is always much appreciated.

Revision history for this message
Phillip Sitbon (phillip-sitbon) wrote :

Update:

Passthrough is now supported in the latest release of PyISAPIe, please let me know if you experience any issues with it.

Cheers,

Phillip

Revision history for this message
Adrian Wilkins (adrian-wilkins) wrote :

That sounds like just the ticket, Phillip (I'm the filer of the tracker item for this on Sourceforge). I'll give it a go when I have a moment next week.

Martin Pool (mbp)
Changed in bzr:
status: Triaged → Confirmed
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.