[rfc] Handling redirects properly.

[Martin Pool]

On 20 Jul 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:
> 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.

The question, as ever, is what you want to test.  There seem to be a few
things:

 - when we get a redirect on the initial format probe, we correctly
   switch to a transport looking at the new location

 - when the server gives back a 30x, we interpret that as the right kind
   of redirection

 - when automatically following redirects, we do the right thing and
   return the contents of the file at the destination.

Having canned responses recorded from various servers seems most useful
for the second, particularly if we expect to have trouble doing it
against different servers.  That might be true for range requests but
I suspect not for redirects.  

So I'd suggest having a server subclass which does a redirect, and then
use that in different ways for these. 

-- 
Martin