- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 3 Oct 2007 00:03:59 +0000 (UTC)
- To: public-appformats@w3.org
I was confused when reading the spec last night because the term "requesting URI" is used to mean something that is not the requesting URI. I recommend changing the term throughout to "referrer root URI" or some such. (IIRC, I invented the concept. So if _I'm_ confused...) "For instance, a specification using the access control mechanism needs to define what the requesting URI is." is wrong; the specification using the access control mechanism needs to define the source for the requesting URI, but the actual requesting URI is defined in section "2.2.3. URI Matching". "up to and including the root element start tag" in step 5 of "2.2.2. Access Check" seems dangerous; I would recommend defining it as being "up to but _not_ including the root element" since otherwise documents like the following could have unexpected side-effects: <script xmlns="http://www.w3.org/1999/xhtml" src="data:text/javascript,alert('test')"/> "If the processing instruction has any other pseudo-attributes than deny, allow and exclude, has not exactly two pseudo-attributes or has both deny and allow specified terminate the overall algorithm and deny access to the resource." in step 5.1 of "2.2.2. Access Check" seems wrong: shouldn't you be able to have just one pseudo-attribute? (i.e. isn't the "exclude" attribute optional?) You have a "Note:" in section "2.1.2. Access-Control HTTP Header" that has the word "may" in it: "As stated by RFC 2616, multiple Access-Control headers may be combined." In section "1.2 Security Considerations", the mention of a "a trusted corporate network" seems odd; I'd change it to "a trusted private intranet" or some such. The security considerations section doesn't mention anything about the danger of allowing arbitrary ports in shared hosting environments. Section "2.2.1. Access Request", second paragraph, second sentence ("This request includes an If-Method-Allowed header specifying the desired method.") doesn't include normative conformance criteria and it is unclear to me if this is because it is redundant with the HTTP spec, or because the spec defines it elsewhere, or due to an error in the text. I recommend that the whole spec be carefully proofread. There are a number of places where the text has typos, grammatical mistakes, or awkward paragraphing. For example "To obtain the values from a space-separated list user agents must replace any sequence space characters (in any order) with a single U+0020 character, dropping any leading or trailing U+0020 character, and then chopping the resulting string at each occurrence of a U+0020 character, dropping that character in the process", "When making requests to resources which before implementing this specification could not accessed", "This specification does make some requirements on such access requests though. [paragraph break] Namely...", or "a subsequent request must be made directly to the retrieved resource its [sic] URI". -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 3 October 2007 00:04:09 UTC