I think it is technically permissible, but unwise for a host of reasons, 
a number of which have been noted in this thread.

It boils down to this:  at the end of the day - and putting aside the 
whole SSL/non-SSL tangent - it is a "relative reference" according to 
the RFC and that begs the question, "Relative to what?"  Is it relative 
to your specific system?  Relative to the value found in the $2?  And 
how is this crucial component - the base-uri/scheme with which to make 
the reference absolute - captured?

And that’s the crux of the issue.  You are looking to address the binary 
choice between http/https, but those are only two possible schemes out 
of many.  Other valid schemes could be:  ftp, sftp, ldap, rtmp, rsync, 
udp, file, etc.

And, without anyway of knowing which scheme is valid, if you dropped the 
'scheme' from the URI and those records made it into the wild, the 
utility of those $u subfields will be substantially diminished, minimally.

Finally, I also suspect that it is uncommon (at best) to find relative 
references in $u (for the reasons above). The RFC recognizes as much, 
noting "a relative reference that begins with two slash characters...are 
rarely used."

Why not just repeat the $u?  This is one of the reasons it is repeatable.

Rgds,
Kevin


On 8/17/15 5:44 PM, Cary Gordon wrote:
> I think that this is a great idea, if you control all of the URLs in your systems. Otherwise unless all of the major browsers drop http — unlikely — it easily has another ten years in it.
>
> Chrome dropped support for SHA-1 a few months ago, and I am sure that it will be another 33 months before all of the old certs are fixed. In other words, the pre-drop certs will all have expired by then and all new ones are SHA-2.
>
> Cary
>
>
>> On Aug 17, 2015, at 3:08 PM, Andrew Anderson <[log in to unmask]> wrote:
>>
>> That said, there is a big push recently for dropping non-SSL connections in general (going so far as to call the protocol relative URIs an anti-pattern), so is it really worth all the potential pain and suffering to make your links scheme-agnostic, when maybe it would be a better investment in time to switch them all to SSL instead?  This dovetails nicely with some of the discussions I have had recently with electronic services librarians about how to protect patron privacy in an online world by using SSL as an arrow in that quiver.