Re: override mask semantics

["Roy T. Fielding" <fi...@liege.ICS.UCI.EDU>]

>> where parms->override is set according to where the directive occurs:
>> 
>>    *.conf   --> override = (RSRC_CONF|OR_ALL)&~(OR_AUTHCFG|OR_LIMIT);
>> 
>>    within <Directory> or <Location> --> override = OR_ALL|ACCESS_CONF;
>> 
>>   .htaccess --> override = core_dir->override;   /* AllowOverride, I assume */
>> 
>> <Limit> and <Files> do not change the override value, which seems odd.
> 
> Not setting <Files> to OR_ALL|ACCESS_CONF is a defenitely a bug, and
> should be fixed. Probably someone (me) just accidentally deleted the
> line.

Hmmm, I don't know.  The reason <Directory> and <Location> can set it to
(OR_ALL|ACCESS_CONF) is because they are only allowed in *.conf.
If <Files> is allowed in .htaccess, then the current behavior is
probably correct.  Hmmm, I guess that begs the question: is <Files>
allowed in .htaccess?

Right now, we have

{ "<Files", filesection, NULL, OR_ALL, RAW_ARGS, NULL },

in which the OR_ALL seems odd to me (it implies that the directory
must have AllowOverride All in order to set anything via <Files>).
I think it should be either RSRC_CONF (meaning only allowed in *.conf)
or OR_NONE (meaning it should inherit the overrides of the context).

Aaarrgghh, hold on -- I have been assuming that the purpose of the
req_override argument was to indicate the union of overrides that
are necessary.  If, instead, it is supposed to indicate the intersection
(as in, this command is allowed if *any* of these overrides are allowed),
then that would explain

    if ((parms->override & cmd->req_override) == 0)
        return pstrcat (parms->pool, cmd->name, " not allowed here", NULL);

Hey RST, can you confirm one way or the other?  That is, does

    (OR_AUTHCFG|OR_LIMIT) mean
         "anywhere that AuthConfig AND Limit are allowed to be overridden"
     or  "anywhere that AuthConfig OR Limit is allowed to be overridden"?

The API.html (and what I expected) led me to believe the former, but
the code is currently doing the latter.

.....Roy

Re: override mask semantics

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

On Wed, 2 Oct 1996, Roy T. Fielding wrote:

> Hmmm, I don't know.  The reason <Directory> and <Location> can set it to
> (OR_ALL|ACCESS_CONF) is because they are only allowed in *.conf.
> If <Files> is allowed in .htaccess, then the current behavior is
> probably correct.  Hmmm, I guess that begs the question: is <Files>
> allowed in .htaccess?

Yes. Of course, you're right. That's why I hadn't set it to that in
the first place. *bonk* Thanks.

> Right now, we have
> 
> { "<Files", filesection, NULL, OR_ALL, RAW_ARGS, NULL },
> 
> in which the OR_ALL seems odd to me (it implies that the directory
> must have AllowOverride All in order to set anything via <Files>).
> I think it should be either RSRC_CONF (meaning only allowed in *.conf)
> or OR_NONE (meaning it should inherit the overrides of the context).

No. OR_ALL means it will work with any AllowOveridde setting - i.e. it
will apply anywhere. OR_NONE means... uh... it applies nowhere. Don't
quite know why you'd want to use that.

-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/