Document, possibly standardize, "plus" scheme convention

[mahmoud]

A new convention has arisen among URLs, as I'm sure many of you have seen, where the scheme specifies both a transport and protocol scheme, separated by a plus ("+") sign.

For instance, Python users can install a package directly from a git repo using: pip install git+ssh://[email protected]/mahmoud/boltons.git.

Given the number of transport-protocol combinations, and the straightforward meaning of most of them, documenting every single one seems excessive. Would it be worthwhile to capture this convention in the documentation?

This usage pattern dates back several years already, and seems beneficial, so I figure it might be good to have it on the board next time the standards committee rolls around :) Thanks!

[mnot]

What would it actually do? I don't think you can assume that every combination will work; e.g., git+ftp doesn't work AFAIK. Each combination seems like it will require documentation of its own (e.g., how Git uses HTTP, how git uses SSH).

[mahmoud]

Talk about a quick response! This isn't so much about the protocol itself, it's actually very URL-intrinsic.

So here's where this comes up. As you know, URLs with a scheme that uses a network location get a '//' whereas those without do not. http://github.com vs mailto:[email protected].

If the standard is enforced strictly, and the scheme is treated as a whole, it's not possible to guess if a scheme implies the URL has a network location. So we don't know whether it should be git+ftp://... or git+ftp:..., despite the fact that you or I can clearly guess.

A manifestation of this can be seen in Python's built-in URL support, here: https://hg.python.org/cpython/file/2.7/Lib/urlparse.py#l41

[mahmoud]

To really boil it down, I think it might be helpful to say something to the effect of "if using a conventional '+'-separated URL scheme, the last segment is what matters to the network location". Nip the ordering spat in the bud while everyone still agrees. (As another example, I believe docker uses http+unix:// to refer to http over unix domain socket) (they should probably be using the file scheme)

[mahmoud]

To rephrase:

If the scheme as a whole is not recognized, and a "+" is present in the scheme, and the last "+"-separated segment is a recognized scheme, it is reasonable for URL implementors to guess that that is the intended scheme for purposes of authority and default port behaviors.

I think that about covers my suggestion :)

[annevk]

If you want to include authority and have it parsed automatically, just use //. I don't think we want to introduce further complexity into the URL parser.

[mahmoud]

@annevk I understand your desire not to complicate the parser even more. The most I can hope for is someone to make a small note of the plus-convention for delineating multiple protocols/schemes. But to be clear, you can't "just use //". Whether or not a URL can have a // is defined on a per-scheme basis. file:///x/y/z is valid, whereas mailto://[email protected] is not.

There are dozens of schemes registered already, and with the + convention, there are dozens more that will likely bypass registration. A sensible heuristic isn't the worst thing to document.

[annevk]

That's true, but then it sounds like something that wouldn't really influence the parser. Better for a library that takes a URL record and does some post-processing.

[mahmoud]

Right, hence my desire to document the convention, for other library implementors like myself.

…

On Feb 9, 2017 2:30 AM, "Anne van Kesteren" ***@***.***> wrote: That's true, but then it sounds like something that wouldn't really influence the parser. Better for a library that takes a URL record and does some post-processing. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH8kao_qm134rYNksmZuBQ-BOHCNBfbks5rauq9gaJpZM4L2AGZ> .

[annevk]

Closing this as it hasn't really come up much and it's also somewhat out-of-scope.

[brainstorm]

Good read!

I suspect that to properly standardize this "+" scheme convention you'd have to go for RFC8615 and generate a ton of URI scheme drafts for IANA for all possible combinations which will in high likelihood be rejected by "the experts" (as noted in the aforementioned RFC)?:

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
https://en.wikipedia.org/wiki/List_of_URI_schemes

Pointing this out since I've been doing some research on this topic for work.

Please let me know if I'm wrong with my assumption(s).