- From: Joseph A Holsten <joseph@josephholsten.com>
- Date: Tue, 27 Jan 2009 08:37:04 -0600
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Cc: HTML WG <public-html@w3.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jan 27, 2009, at 7:26 AM, Lachlan Hunt wrote:
> Joseph A Holsten wrote:
>> I've posted the merged version of Lachlan and my drafts here:
>> http://josephholsten.com/about-uri-scheme/draft-holsten-about-
>> uri-scheme.txt with inline comments and editing marks in html here:
>> http://josephholsten.com/about-uri-scheme/draft-holsten-about-
>> uri-scheme.html and source control here:
>> http://github.com/josephholsten/about-uri-scheme/
>> My changes mostly amount to adding the required IANA and Security
>> Considerations sections.
>> As to whether different browsers use the exact same representation
>> of the about:blank resource, I think that is content type specific
>> decision, and belongs in the HTML5 spec. I'd care more that the
>> DOM is identical than the actual document.
>
> The DOM is generated based on the content type, and for
> interoperability reasons this needs to be defined as text/
> html;charset=UTF-8. It should go into the RFC, rather than HTML5,
> because ideally, all uses of about:blank will be handled the same
> in all applications.
>
> This statement is grammatically incorrect.
>
> "If the application may use a document of MIME type 'text/html' and
> character encoding 'UTF-8', about:blank SHOULD be represented with
> an empty document."
>
> I suggest you use the phrasing from my draft and add a reference to
> HTML5.
Sounds fine.
>> Lachlan, I don't know what you mean when you mention Origin in
>> Security Considerations. Care to explain?
>
> I meant to say something about the security implications in terms
> of the origin as defined in HTML5 [1].
That's enough to recommend action, but doesn't explain the security
of not doing it. I don't seem to understand why well enough to
explain it.
> I also noticed you omitted the opera: URI examples that I included
> in my draft [2]. Was that intentional, or had you just used the
> old revision?
Old revision. Added.
> Finally, I concur with all of Julian's suggestions and was going to
> suggest roughly the same changes.
+1
> Julian Reschke wrote:
>> - "abouturi = "about:" segment" - restricting to segment sounds good,
>> but does this reflect reality?
>
> Looking at the syntax from RFC 3986:
>
> segment = *pchar
> pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
> unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
> pct-encoded = "%" HEXDIG HEXDIG
> sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
> / "*" / "+" / "," / ";" / "="
>
> That doesn't look right. Mozilla uses a query string for some [3],
> which isn't permitted by that syntax.
Noted
> I'm not sure about supporting percent encoding. Testing with the
> URI about:confi%67, these are the results:
>
> Opera: The address bar changes to "opera:config", but still returns
> an error.
>
> Firefox: Says the URL is not valid.
>
> IE8: Presents error page "Navigation to the webpage was cancelled".
>
> Safari: Treats all about: URIs the same as about:blank, so unaffected.
>
> Chrome: Treats all unknown about: URIs the same as about:blank, but
> testing with about:%63ache, the address bar is resolved to
> about:cache, but still returns a blank page.
>
> So it appears that percent encoding isn't really supported among
> the browsers. However, I'm not sure if we want to forbid them.
> I'm inclined to make the syntax as lenient as possible so future
> implementations have few restrictions on what they can do.
>
> [1] http://www.whatwg.org/specs/web-apps/current-work/#origin
> [2] http://lachy.id.au/dev/specs/about-uri/draft-lachy-about-uri.txt
> [3] http://en.wikipedia.org/wiki/About:_URI_scheme#Mozilla-
> specific_about:_addresses
And I had so hoped the syntax of this one would be simple. I'm
inclined to say that percent encoding should be allowed, especially
in the query. Anyone got a better idea?
http://josephholsten.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkl/HBAACgkQrPgSa0qMrmFt3wCfSk1UvAb1pobHaP4LShMdwyvi
pXYAnR4sSq8JP/fCrTTCbKsY1/PUU1rs
=L5nY
-----END PGP SIGNATURE-----
Received on Tuesday, 27 January 2009 14:37:53 UTC