Re: [urn] How widely deployed are "non-strict parsers" in RFC 3986

On 9/26/2016 12:50 AM, Martin J. Dürst wrote:
> This question came up on the URN mailing list, but is essentially an 
> URI question, so I'm copying the URI list and the co-author of the URI 
> spec that I think will know the answer.
>
> RFC 3986, in section 5.2.2 
> (https://tools.ietf.org/html/rfc3986#section-5.2.2), mentions the 
> following:
>
>       -- A non-strict parser may ignore a scheme in the reference
>       -- if it is identical to the base URI's scheme.
>       --
>       if ((not strict) and (R.scheme == Base.scheme)) then
>          undefine(R.scheme);
>       endif;
>
> The term "non-strict" isn't found in any other place in RFC 3986. The 
> question is how widely deployed such "non-strict" parsers are. E.g. 
> are these things that still existed in 2005 when RFC 3986 was 
> published, but are now essentially extinct, or e.g. did and do all 
> browsers behave that way.
>
> Many thanks for an enlightening answer.

The way I've seen such a parser work is:
Say your base is:
http://www.seantek.com/asn1teletexer/

and you want to link to:
http://www.seantek.com/asn1teletexer/asn1teletexer-0.7.zip

Using a "non-strict parser", you can use <a 
href="http:asn1teletexer-0.7.zip"> , and it will do the job. You should 
look at the top of Page 32 of RFC 3986: it says that if R.scheme is 
defined, then R is not actually a relative URI, so R is just used as the 
URI itself. A strict parser will produce a URI of 
"http:asn1teletexer-0.7.zip", which is not dereferenceable.

RFC 3986's pseudocode could have been written as:

if defined(R.scheme) and ((strict) or (R.scheme != Base.scheme))) then
    (...T = R...);
else
    ...

I have seen some web browsers that will handle https: , such as: <a 
href="https:asn1teletexer-0.7.zip"> producing 
"https://www.seantek.com/asn1teletexer/asn1teletexer-0.7.zip". I cannot 
point to specific web browsers at this time, but you could construct a 
very simple webpage and see what happens.

Regards,

Sean

Received on Monday, 26 September 2016 16:56:50 UTC