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 <andrew_at_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.
Received on Tue Aug 18 2015 - 11:25:11 EDT