Re: Last Call: <draft-holsten-about-uri-scheme-06.txt> (The 'about' URI scheme) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/17/11 7:25 AM, Lachlan Hunt wrote:
On 2011-06-17 06:32, Boris Zbarsky wrote:
On 6/17/11 12:03 AM, Mykyta Yevstifeyev wrote:
not
clearly compatible with the web security model,
How?

"about:blank" in particular is magic with respect to security on the web
in various ways (e.g. it can end up same-origin with http:// pages). So
I think we do need to specify exactly when this magic security behavior
takes place.

The spec is not meant to imply that the special same-origin behaviour
for about:blank is to be inherited by any other about URI, even if other
URIs also return a blank document. Perhaps, I need to make that clearer
in the spec.

Yes, but is it meant to be inherited by "about:blan%6b" ? That's the issue that needs sorting out in terms of normalization, for example.

The current spec draft explicitly says that "about:blan%6b" and "about:blank" are equivalent.

I just did some testing on that, since it looks like it won't happen otherwise. You can see the testcase I used at the end of the mail. Results are:

Gecko all versions: URI not loaded at all
Chrome 11 stable: document URI is still shown as escaped,
                  security magic is done
Chrome 14 dev: same as Chrome 11 stable
WebKit tip: same as Chrome 11 stable
Safari 5: same as Chrome 11 stable
Opera 11.11: URI not loaded at all (or at least the subframe's load
             event doesn't fire).
IE9: Loads error page in the subframe and alerts an access denied error.
     This is the same in stadards, IE8, IE7, and quirks modes (though
     the textual representation of the error varies).

I didn't bother testing older Opera versions; if someone cares please feel free to do so.

Note that some browsers have behavior that differs between iframes and the url bar. For the url bar, I observe the following behaviors for "about:blan%6b":

Firefox all versions: alert saying the URI is invalid and cannot be
                      loaded.
Chrome 11: URL bar shows "about:blank", content area shows a blank
           document.
Chrome 14: redirects to chrome://blank which then gives an "invalid
           URI" error page
WebKit tip: URL bar shows "about:blan%6b", content area shows a blank
            document.
Safari 5: As WebKit tip.
Opera 11.11: Redirects to "opera:blank" which gives an "Invalid address"
             error page.
IE9: URL bar shows "about:blan%6b" and an error page is shown.

So it could be argued that Chrome 11, WebKit tip, and Safari 5 do what the spec currently calls for. No other browser does. And Chrome 14 is inconsistent in how it handles this URI depending on the context it's encountered in.

-Boris

Testcase:

<!DOCTYPE HTML>
<body>
  <iframe id="iframe"></iframe>
  <script>
    var i;
    onload = function() {
      i = document.getElementById("iframe");
      i.onload = function() {
        try {
          alert(this.contentDocument.documentURI);
          alert(this.contentDocument.documentElement);
        } catch(e) { alert(e); }
      }
      i.src = "about:blan%6b";
    }
  </script>
</body>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]