 |
 |
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.