All I'm trying to say is that if we're going to represent this as a
mechanism that specifications can use however they like so long as they
specify allow, deny, and default behaviors, then we run the potential
that specifications which both use "Content-access-control" as their
header might separately define allow, deny, and default behaviors that
lead to conflicts on the same document. My example was intended to be
illustrative. If we specify that each specification referencing this
mechanism should also specify their own independent header and
processing instruction name then there is no opportunity for conflict.
I also understand that HEAD requests check for document existence. I
was asking if we have a use-case where user-agents need to establish
allow, deny, and default for a document based solely on the HEAD
information without consideration of the processing instructions. As
currently written the working draft doesn't support that case.
Feels like we're talking past each other at this point, so perhaps the
two of us can chat by phone sometime this week?
--Brad
Anne van Kesteren wrote:
On Sun, 29 Oct 2006 00:49:21 +0200, Brad Porter <[EMAIL PROTECTED]> wrote:
[...]
The problem with letting other specifications define how to use the
mechanism is that unless we specify some way to specify
access-control-for-function-X, then two specifications might declare
two different purposes for the header which conflict.
For instance, a specification might say "if access-control is deny
for a document to be displayed in a sub-frame, the contents of that
document must not be displayed in the sub-frame." Another
specification might say "if access-control is deny for a document to
be requested by XmlHttpRequest, the contents of that document must
not be parsed and made available to the application."
As an author, if you want to allow your content to be displayed as a
sub-frame, but not allow your content to be accessed via
XmlHttpRequest, what do you do?
I don't really see what the use case is for that, actually. Also, the
specific examples you cite don't really seem to match the real world.
As I said, I could go either way, but if we just want to say "this is
a mechanism independent of function, here you go, you must specify
the functional behavior in its context", then I think we need to
enable a way to say "access-control-for-function-X". Currently, the
specification states "
Was something dropped here?
[...]
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...)
Right, I'm suggesting we either want to consider those potential use
cases, or we should state that this is not intended for that purpose
and it isn't appropriate to reference/use this mechanism for anything
other than XML-read
I'm suggesting it's out of scope. I don't think we should try to
tackle all potential use cases and their respective problems. If we
want to go there, fine, but I think it will take a lot of time to come
up with all the potential scenario's and how they apply to those. Not
to mention that it wouldn't address anything for new specifications.
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.
The specification does currently say that rules may be specified in
both places and that all rules must be used. Consequently, the most
appropriate reading is that HEAD-only requests are insufficient to
make a determination. Do we have a use-case for HEAD-only requests?
Checking if the document exists without having to download the whole
document. Not sure what you mean with "HEAD-only" by the way...
--Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
