httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paritosh Shah" <>
Subject Re: thoughts on ETags and mod_dav
Date Thu, 25 Oct 2007 19:05:07 GMT
I had another look at ap_meets_conditions(), I guess what you say is
true. The current ap_meets_conditions() *does* assume resource exists
( although it does not explicitly state that ). And in that case
NO_RESOURCE would indeed be more appropriate.

- Paritosh.

On 10/25/07, Chris Darroch <> wrote:
> Paritosh Shah wrote:
> > There are really three states here ( wrt ap_meets_conditions())
> > 1. resource exists
> > 2. resource does not exist
> > 3. nothing is known about existence of the resource
> >
> > Currently ap_meets_conditions() does not make any assumptions about
> > existance of the resource ( case 3 ). If we use a NO_RESOURCE flag
> > without addtional "Y" or "N" values, we can really only cover 2 states
> > ( flag is set and flag is not set ). In the case that flag is not set,
> > we cannot directly assume that the resource exists, because this runs
> > the risk of breaking a lot of existing modules which do not set any
> > flags.
>    I don't think it's that complex (although of course I may be
> missing something).  The current code assumes the resource exists.
> All that's needed, I believe, is a flag which, when present, indicates
> that the resource does not exist.  We must continue to assume that
> the resource exists when the flag is not present, to avoid breaking
> things, so I don't see a need to add an explicit "yes, it exists"
> flag state -- that's just adding confusion, IMHO.
>    In an ideal situation (maybe for httpd 3.0), we could have a flag
> like r->exists which must be set to either 0 or 1.  But, since we
> want a backportable solution, we're looking at adding an optional
> flag to r->notes instead.
>    Now, when that flag is not present, the code in ap_meets_conditions()
> must assume (as it does now) that the resource exists.  That's the
> current behaviour, and it's correct for all cases except those where
> a module (like mod_dav) needs to indicate that the resource doesn't
> exist.  So our flag is only going to be present at all in a few
> cases, which means there will be a degree of mystery to the code
> no matter how to slice the problem.
>    If we use a flag named something like "RESOURCE_EXISTS", then
> what we care about is the case when that flag is set to "false",
> which means we've also got to have a "true" state as well.  What I
> dislike about that is the code then has to assume that when the
> flag isn't present -- i.e., is undefined -- it should proceed as if
> the flag was set to the "true" state.
>    But, that runs counter to a lot of other programmatic practice.
> A SQL expression like "WHERE foo = 1" will fail if foo is NULL,
> for example.  Or in (non-strict) Perl, an undefined variable is treated
> as zero/false/empty/etc. by default.
>    That's why I see a flag named something like "NON_EXTANT_RESOURCE"
> as a little better.  It doesn't need to have true or false values;
> its presence alone indicates the opposite case from the default
> assumption.
>    Anyway, I'll continue to think it over for a bit before I commit
> anything; please let me know if I've missed something!
> Chris.
> --
> GPG Key ID: 366A375B
> GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

View raw message