I think I've addressed all the issues:
http://dev.w3.org/2006/waf/access-control/
On Wed, 03 Oct 2007 02:03:59 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
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...)
Done. Thanks for reading by the way!
"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".
Fixed.
"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')"/>
Changed.
"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?)
Made this requirements better. "exclude" is indeed 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."
Reworded the note.
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.
I removed this paragraph as I'm not sure why it was there. I hope that's
ok.
The security considerations section doesn't mention anything about the
danger of allowing arbitrary ports in shared hosting environments.
I added this. I also elaborated on some other security points and added
that authors should ensure to make applications where GET is side-effect
free.
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.
This header has been reworded and I also made it clear what it means to
support it.
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".
I fixed these instances. I'll take it up with the WG about finding someone
to proofread our, or mine at least, documents.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
