Re: [access-control] Minor issues

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 <ian@hixie.ch> 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/>

Received on Thursday, 4 October 2007 12:11:29 UTC