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 <and...@lirn.net> 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.
