- 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