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. Because even though it can say deny= in the processing instruction that isn't actually true for same-origin requests for instance. And for non same-origin requests the default is deny. Therefore the allow / exclude mechanism makes sense. It also cateters for:

  allow <*.example.org> exclude <*.public.example.org>
  allow <webmaster.public.example.org>

I'm not really convinced we should throw that away in favor of deny=.


Also, you still need to have allow and exclude for the processing instruction so supporting the same logic for the HTTP header makes more sense to me. Basically:
    rule ::= type (pattern)+ ("exclude" (pattern)+)?
   type ::= allow | deny

My propsal was that we have "allow", "deny" and "default" for the HTTP header and "allow" and "deny" for the PIs. The logic would be exactly the same between them. We could even have "allow", "deny" and "default" for the PIs and let the processing be exactly the same, the effect would be that for PIs "deny" and "default" would have the same effect.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply via email to