W3C home > Mailing lists > Public > public-iri@w3.org > May 2011

Re: Non-hierarchical base URLs (was Re: draft-abarth-url-01 uploaded)

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 3 May 2011 12:24:16 -0700
Cc: public-iri@w3.org
Message-Id: <A0C4FFB1-3F02-42BE-B596-37D96ABC0F63@gbiv.com>
To: Maciej Stachowiak <mjs@apple.com>
On May 3, 2011, at 11:00 AM, Maciej Stachowiak wrote:
> My example was meant to illustrate a case where relative resolution against a non-hierarchical URI scheme may actually come up in Web content. I draw no conclusions about whether any specific behavior is required for Web content. Although testing 5 browsers and getting 4 different answers implies to me that we really need a clearly defined behavior for this case. If you would like to see an example of relative resolution against a non-hierarchical URI that has full interop, try this:
> <iframe id=foo src="about:blank" onload="test()"></iframe>
> <script>
> var doc = document.getElementById("foo").contentDocument;
> var anchor = doc.createElement("a");
> anchor.setAttribute("href", "foo.html")
> doc.body.appendChild(anchor);
> alert(anchor.href);
> </script>
> I believe you will consistently get resolution against the URL of the parent document. I am reasonably confident cases like this *do* affect Web compatibility, though the deviation here is outside the scope of URL parsing itself.

Color me confused.  I have never seen actual (non-test) content
on the Web that has an arbitrary base URI (one that is unusable
in practice).  What is the use case?  Is this a javascript idiom
that I am not familiar with?

> Anyway, this is why I originally asked whether any deviation from RFC processing for valid all-ASCII URIs is required by Web compatibility. I am less confident than Adam that it is in fact required. I *am* confident that URIs that are invalid per the grammar or contain non-ASCII characters need to deviate from what IRI says, however, even in cases where they are valid IRIs.


Received on Tuesday, 3 May 2011 19:24:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:42 UTC