- From: Anne van Kesteren <annevk@opera.com>
- Date: Sun, 29 Oct 2006 01:35:19 +0200
- To: Brad Porter <brad@tellme.com>
- Cc: "WAF WG (public)" <public-appformats@w3.org>
On Sun, 29 Oct 2006 00:49:21 +0200, Brad Porter <brad@tellme.com> 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/>
Received on Saturday, 28 October 2006 23:36:24 UTC