W3C home > Mailing lists > Public > public-appformats@w3.org > May 2007

Re: [access-control] update from the editor

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 10 May 2007 20:10:23 +0000 (UTC)
To: Anne van Kesteren <annevk@opera.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-ID: <Pine.LNX.4.62.0705101945300.17581@dhalsim.dreamhost.com>

On Thu, 10 May 2007, Anne van Kesteren wrote:
> On Wed, 09 May 2007 21:28:12 +0200, Ian Hickson <ian@hixie.ch> wrote:
> >
> > In 2.1, ""deny" rules can be used by authors to deny read access from 
> > external resources to the entire server a simple way without having to 
> > check each individual XML resource that may have <?access-control?> 
> > processing instructions specified." is somewhat confusing to a first 
> > time reader because the PI hasn't yet been met.
> > 
> > In fact it's still confusing to me now. I think your prepositions are 
> > all wrong. I'm not really sure what you're trying to say.
> 
> I tried to clarify it.

Yeah, that's better. It might help readers understand the sentence more if 
you explicitly point out the assumption that headers can be set across the 
entire server even if files can't be modified across the entire server.


> > 2.2 doesn't actually say that if the MUSTs are violated that the 
> > resource is put in error.
> 
> You mean to make it more clear to authors? Because when something is 
> rejected is now determined by the algorithm in section 3.

It's fine now (looks like you removed the "in error" bits).


> > In 3: "The match list and exclude list are both unordered lists of 
> > access items." -- "the" match list? "the" exclude list? There are 3 of 
> > each! This should probably be in the plural or something.
> 
> Made the definitions plural.

That broke the cross-reference to "exclude list". :-(


> > Is there a difference between "terminate this algorithm" and 
> > "terminate this algorithm (process the next list item)"?
> 
> I rewrote most of this sub algorithm handling to make it much more clear 
> (hopefully!) what needs to be done.

Looks better.

One thing I didn't notice before -- you have "for each 
Content-Access-Control header and rule within" but shouldn't that just be 
for each rule, not for each header and rule? Surely you got rules when you 
parsed the headers, so you don't need to do anything for each header 
anymore at this point.


> > "user agents must grant access to the resource" can we make that a 
> > SHOULD instead of a MUST?
> 
> Makes sense, addressed.

Looks good. It's sort of weird now because the MUST for the deny is at the 
top of section 3, but the SHOULDs override it in the algorithm, but I 
guess that's ok.


> > It isn't completely clear to me what the "overall algorithm" is. The 
> > sub-algorithms have <ol>s, maybe the overall algorithm should too? I 
> > don't know.
> 
> I put it <ol>. It probably needs some further tweaking to make it clear 
> when it's invoked and such.

Looks good.


The note "This means that the attribute value can not be the empty 
string." seems to be wrong -- why does it mean that?


> > I can't really comment on the "match" algorithm because I don't know 
> > what Request URL is supposed to be. For example, is it expected to be 
> > an absolute URL always, or can it be relative? What does it mean for 
> > the origin not to have a scheme? Why would you ignore the scheme if 
> > it's not followed by "://" ? How can it not have a port? Are 
> > non-host-based- authority schemes allowed?
> > 
> > Step 9 doesn't specify the order.
> 
> I tried to fix these as well.

Step 1 is backwards (are you setting request URL or origin?).

The definition of requestURL doesn't handle request URLs that are not 
host-based authorities (e.g. data: URLs). I assume you just auto-deny for 
those? Or, as the note says, maybe it should be based on origin? Hm.

How can item be "*"? Doesn't that not match the syntax?

How about if requestURL is http://example.com:81 and item is 
http://example.com -- should it be allowed? Even though the implicit port 
is 80, not 81?

Step 5 would, given those examples, result in

   "http://example", "com:81"
   "http://example", "com"

...respectively, which I'm assuming isn't what you want (shouldn't they be 
dropping the scheme:// and :port parts, if present?).

What does "equal" mean in step 7.4? Case-insensitive?

In step 7.4: "apply to these set of steps to the next list item" looks 
like it has an extra "to" or something.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 10 May 2007 20:10:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:22 GMT