There seem to be two differences between what the draft specifies right
now and what Gecko, at least, does:
1) Section 5.3 says:
Applications SHOULD resolve unrecognized "about" URIs in the
same way as "about:blank".
Gecko treats unknown about:* as unparseable URIs, and is not likely to
change that behavior. While that's allowed by the SHOULD, it's not
clear to me why this is a SHOULD as opposed to a MAY, nor is it clear
why this is present at all. In particular, as specified this will cause
situations where an empty resource is silently returned instead of a
failure that the consumer can notice (e.g. in the DOM case via error
event handlers and the like).
2) Section 6 says:
For example, "about:blank", "about:blan%6B" and "about:blan%6b"
are equivalent
In Gecko they are not. The string after ':' is treated as a literal
string; when looking up a way to handle the URI the second and third
URIs above are treated as unparseable by Gecko in its default
configuration. Changing this has some security implications that would
require careful auditing of not only Gecko code but some specifications
(e.g. HTML5 defines certain special-case security behavior for
about:blank that's not obviously safe to apply to the other strings above).
The same section says:
Similarly, "about:blank%3F" is not equivalent to "about:blank?".
which I think is trying to explain by example that only unreserved
characters need to be unescaped. But that assumes an implementation of
RFC 3986 which may or may not be the case in web browsers (and is NOT
the case in Gecko, for example, for various web-compatibility reasons).
Unless there are very strong reasons for it, I would recommend that no
normalization is performed on about: URIs, period.
-Boris
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf