httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paritosh Shah" <shah.parit...@gmail.com>
Subject Re: thoughts on ETags and mod_dav
Date Mon, 19 Nov 2007 16:38:22 GMT
Another possible approach would be to create a new
ap_meets_conditions_2() with resource_exists as an explicit argument (
instead of implicitly using r->notes ). Till the next major release we
could just make the current ap_meets_conditions() call
ap_meets_conditions_2() with resource_exists as 1. Later we can make
ap_meets_conditions_2() the default ap_meets_conditions().

-Paritosh.
p.s. This approach was proposed by Paul Querna when I had a little
chat with him at apachecon.

On 10/25/07, Paritosh Shah <shah.paritosh@gmail.com> wrote:
> 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 <chrisd@pearsoncmg.com> 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
> >
>

Mime
View raw message