On Thu, 03 May 2007 15:33:12 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Anne van Kesteren wrote:
On Thu, 03 May 2007 13:24:01 +0200, Jonas Sicking <[EMAIL PROTECTED]>
wrote:
I know, but I propose we change that since I think the current
algorithm is hard to easily see what results it produces, as you
described in the initial mail in this thread.
With the algorithm you are proposing now that is true as well, fwiw.
What is true?
That it's hard to see what the results will be. Because for a same-origin
request a deny rule won't have any affect. In fact, the whole algorithm
wouldn't apply.
Because even though it can say deny= in the processing instruction that
isn't actually true for same-origin requests for instance.
That is going to be true for any solution we are building, so I don't
see how that is an argument for or against any algorithm.
It was not an argument against the algorithm.
And for non same-origin requests the default is deny. Therefore the
allow / exclude mechanism makes sense.
Just using allow/exclude will not cater for all usecases I brought up in
my initial proposal, i.e. that you want to be able to, using headers,
deny access to all files from all or a set of remote servers.
Yes, my proposal was to allow "deny <rules> exclude <rules>" in addition
on HTTP headers.
Having said that...
[...]
Have "allow", "deny" and "default". There is no "exclude". Order is
important. If headers say "deny" then immediately deny. If headers say
"allow" or "default" check with PIs. If PIs say "deny" deny. If PIs say
"allow" allow. If PIs say nothing and headers said "allow" allow.
Otherwise deny.
If we allow "default" in PIs or not doesn't really matter to me. In the
end they are useless, but it would be consistent.
So what would happen for:
Content-Access-Control: allow <*.bar.com>, deny <*.bar.com>
You seemed to imply that ordering was important, but I wonder if that's
intuitive. I would personally be fine with your proposal though. I'm not
sure Thomas Roessler would be, but then he didn't chime in anymore to
argue about it.
(I hope we can resolve this soonish (though it's mostly me that's lacking
in fast replies, sorry about that) so I can update the algorithm once
again and get the specification re-published.)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
