[MERGE] HTTP redirection
Aaron Bentley
aaron.bentley at utoronto.ca
Tue Feb 13 21:34:08 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 ?
Well, I would like "bzr (merge|pull|patch) http://example.com/bundle" to
work whether example.com/bundle redirects to www.example.com/bundle or not.
I don't see any benefit in failing if we encounter a redirect while
attempting to download a patch or bundle. Avoiding the failure would
mean manually handling the redirect.
Is there something I'm missing?
> 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.
The earlier notion of hints would have done that. It would mean
defaults were as reliable as possible, while providing optimal
performance for redirected bzrdirs.
> 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).
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).
That's fine for bzrdirs. It's other uses of transport that I was
thinking of.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF0i7Q0F+nu1YWqI0RAkBwAJ0Xo/bmVF7xf/r3o3y9Zy35Uwy/dQCfRjfX
8Qu4M5TJcayTB5c/rMb6wrI=
=kh7w
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list