On Sat, 28 Oct 2006 17:22:23 +0200, Brad Porter <[EMAIL PROTECTED]> wrote:
I can go either way on this. The original NOTE was targeted to a very
specific use-case and not intended to be a generalized access
mechanism. That use case (XML read by applications running in a
browser) is an important use case by itself.
I agree. This specification doesn't prohibit that though. VoiceXML would
just say that for non-same-origin resources the access control policy as
defined in [ACCESS-CONTROL] is applicable and what it would mean for that
resource to be in "default", "allow" or "deny" state.
I don't feel like we've analyzed enough general use-cases for
access-control to say that the mechanism is sufficiently general for the
variety of use-cases that have been mentioned (restricting access to
images, etc.).
Note that my proposal is not to make it generic. It just says that other
specifications have to define when you have to apply the access control
policy to a resource and what it would mean for such a resource to be in
one of the three returned states.
That said, we could also leave that analysis exercise to those writing
the specification that references this. I do worry that if there are two
separate access-control use cases applicable to a single document
(disallow access for X, but allow access for Y) then we could be in
conflict.
I don't really understand this.
The allow and deny ruleset, together with the request URI (referrer)
form an input for the access control policy. The outcome is either
"access denied", "access granted" or "default" (or something along
those lines).
Specifications using this specification must define for which resources
the access control policy is applicable. Those specifications must also
define what "access denied", "access granted" and "default" mean in the
context of that specification (throwing an exception, etc.). (XXX: I
suppose that in most cases "default" is treated as "access denied". Not
sure how to say that here though.)
Yes, though if we want to make it general, I don't think we can specify
a default. For instance, the <img src=""> case should probably default
to allow.
In the case of <img src=""> the whole access control policy probably
doesn't apply at all. (Unless you want it and in that case you'd have to
define that in the relevant specification...)
XXX: Probably say something about this only being safe for GET and HEAD
requests.
When fetching a resource the following algorithm must be followed:
When a resource is retrieved over HTTP extract a deny and allow ruleset
from the Access-Control (XXX: Content-Access-Control?) header(s). That,
together with the request URI, forms an input for the access control
policy. If the result is "access denied" return that and terminate the
algorithm.
I missed the justification for HTTP overriding document level? Is this
just to support priority of protocol over content? The use case that a
web-server might generally disallow, but a document wants to
specifically allow in certain cases seems quite valid.
Something like
Content-Access-Control:deny="*"
<?access-control allow="foobar.com"?>
I suppose that's a valid issue. I'm fine either way so I suggest the
specification says to take both into account and only HTTP for HEAD
requests.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
