[MERGE] HTTP redirection

[Vincent Ladeuil]

>>>>> "aaron" == Aaron Bentley <aaron.bentley at utoronto.ca> writes:

    aaron> Vincent Ladeuil wrote:
    >>>>>>> "aaron" == Aaron Bentley <aaron.bentley at utoronto.ca> writes:
    >> 
    aaron> Aaron Bentley wrote:
    >> >> Vincent Ladeuil wrote:
    >> >>> After discussions with Robert at NlSprint, John on IRC and Robert
    >> >>> again on IRC, here is a new attempt at http redirections.
    >> >> 
    >> >> I think this is very close to mergeable.
    >> >> 
    >> >>> - By default http do not redirect silently but instead raise the
    >> >>> RedirectedRequest exception,
    >> >> 
    >> >> I'm a little sad to see that removed, because I use
    >> >> transports elsewhere (e.g. 'bzr patch' from bzrtools) and
    >> >> I'll have to manually handle redirects now.
    >> 
    >> Are you sure you have to ?

    aaron> Well, I would like "bzr (merge|pull|patch)
    aaron> http://example.com/bundle" to work whether
    aaron> example.com/bundle redirects to www.example.com/bundle
    aaron> or not.

bundle ! Man, you said so from the beginning, I'm slow to understand ;)

Ok, I will look at that (but not before a few days unfortunately).

I agree that it's a merge-stopper.

But just to fully explain my point of view on that point, I think
that never following http redirections is a good policy because I
can't think of "good" uses of it for bzr. I prefer (as a user) be
informed that "things" have moved and that I should upgrade my
environment that paying bad performances without knowing why.

    aaron> I don't see any benefit in failing if we encounter a
    aaron> redirect while attempting to download a patch or
    aaron> bundle.  Avoiding the failure would mean manually
    aaron> handling the redirect.

Yes. I think it should be rare (like once by month) enough that
gaining the information will be a good price to pay for a manual
use of --remember (which, by the way, would be even harder to get
right !).

    aaron> Is there something I'm missing?

No no, *I* did.

    >> Robert gave this test case:
    >> 
    >> host A that redirects /foo/bar -> host B
    >> /foo/gam -> host C
    >> t = get_transport(http://A/foo/bar)
    >> t.read('.') # to ensure connection occurs
    >> t.clone('../gam').base == http://A/foo/gam
    >> 
    >> For which I have no simple solution that will:
    >> - make that test pass,
    >> - *and* avoid redirecting every request.

    aaron> The earlier notion of hints would have done that. 

But Robert was against that. I leave him explain why (I think I
agree with him but I don't understand enough to explain it
clearly).

So I put robert and john in copy so that they can explain that ;)

    aaron> It would mean defaults were as reliable as possible,
    aaron> while providing optimal performance for redirected
    aaron> bzrdirs.

The initial plan, yes.

    >> We choose to not follow arbitrary redirections because the
    >> other cases we could imagine was pathological (like a
    >> redirection of a sub-directory of .bzr).

    aaron> Sure.  That's probably harmless.

    >> The behavior now, is that the user will get a exception
    >> (RedirectRequested) and can act accordingly (for the other cases
    >> than branch redirection).

    aaron> That's fine for bzrdirs.  It's other uses of transport
    aaron> that I was thinking of.

And that these other uses that my limited (but expanding thanks
to all) knowledge was unable to find ;-)

   Vincent