[rfc] Handling redirects properly.

John Arbash Meinel john at arbash-meinel.com
Thu Jul 20 20:36:25 BST 2006


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

John Arbash Meinel wrote:
> Martin Pool wrote:
>>> On 19 Jul 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:
>>>> Basically, we would have something like:
>>>>
>>>> try:
>>>>   format = BzrDirFormat.find_format(a_transport)
>>>>
>>>>   ...
>>>> except RedirectRequested, e:
>>>>   note('URL %s has been redirected to %s', e.old_url, e.new_url)
>>>>   a_transport = get_transport(e.new_url)
>>>>
>>>> I think this puts the functionality right about where we want it. So
>>>> that when we go to open a new branch, we get redirected to the correct
>>>> location.
>>> I agree with the basic idea of raising an exception on redirects, and of
>>> using them to switch entirely to a different directory.  If you would
>>> like to go into this that would be great, but there are some things to
>>> consider:

There is another issue with all this work. How do we want to test it?

There were similar issues with handling MultiRange requests.

One thing I was thinking was we could hijack an http server, with a
couple possibilities:

1) Only serve up scripted responses. So we generate a logfile from a
real conversation, and basically just play back the responses.
For something like this, we probably want to assert the requests are
made in the expected order.

2) Act like a normal server, but if a request matches a list of canned
responses, return the canned response. In this mode, we just hijack a
few responses out of the 100s we have to give for something like a 'bzr
branch' request.

I think whatever we decide can *probably* be implemented with a custom
RequestHandler class, and then we parameterize our current Http test
objects so that they can be setup with a custom request handler.

I think it wouldn't be too bad to be able to give custom responses. I'm
trying to gauge how much worth it has, versus the effort to implement.

John
=:->

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

iD8DBQFEv9s5JdeBCYSNAAMRAhyaAKCy4xDivTc6KUhHgxY1DCucgQ21JwCg0eTY
Sfa/8LhIloUg6Re7kQ0M9kA=
=vWQb
-----END PGP SIGNATURE-----




More information about the bazaar mailing list