[MERGE] Register netloc protocols at 'register_transport_proto' time

Vincent Ladeuil v.ladeuil+lp at free.fr
Thu Oct 25 11:17:12 BST 2007


>>>>> "john" == John Arbash Meinel <john at arbash-meinel.com> writes:


<snip/>

    john> ^- I'm just going to consider it:
    john> https://bugs.launchpad.net/bzr/+bug/122258

This one is obsolete now in the auth.ring branch where I just
extract credentials before urlparse has a chance to look at them
:)

    john> And submit my changes.

    john> I'll look at pulling in urlparse. But I also had
    john> another thought. What about this in _split_url:

    john>   (scheme, netloc, path, params,
    john>    query, fragment) = urlparse.urlparse(url, allow_fragments=False)
    john>   if netloc == '':
    john>     # Must not have been registered
    john>     register_urlparse_netloc_protocol(scheme)
    john>     (scheme, netloc, path, params,
    john>      query, fragment) = urlparse.urlparse(url, allow_fragments=False)

    john> Because ConnectedTransport._split_url sort of already knows that everything
    john> needs to have a netloc (since that is the host we are connecting to.)

This looks like the right place... so far. But a little daemon is
telling me that this will not be enough... there is still a
pending bug around redirections.

    john> I don't really like having it as a side effect,

Me neither. And that's very bad from a test point of view since
it will be even harder to unregister.

    john> but it does mean that all protocols that get used will
    john> get registered, without having to register all
    john> permutations of all decorators ahead of time.

I may have to look more closely but I viewed the urlparse pull in
as an occasion to expliticely scan the scheme between the
decorators and the real scheme used, which is another way to
avoid the registration of the combinations.

    john> Also, because urlparse.uses_netloc is a list, parsing
    john> time will slow down when we get 100s of them in there.

This could be completely avoided by the proposition above.

     Vincent



More information about the bazaar mailing list