[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Gack! Weirdo DAV bug.

From: Ryan Bloom <rbb_at_covalent.net>
Date: 2001-11-17 06:12:51 CET

On Friday 16 November 2001 06:49 pm, Greg Stein wrote:

> The current logic is basically:
> if (method_number != M_GET)
> return do_get();
> if (method_number != M_PROPFIND)
> return do_propfind();
> if (method_number != M_INVALID)
> return DECLINED;
> if (strcmp(method_name, "REPORT") == 0)
> return do_report();
> if (strcmp(method_name, "MERGE") == 0)
> return do_merge();
> We use the M_INVALID to shortcut a bunch of strcmp() operations on the
> method name. Switching that logic over to use the APIs is not going to save
> us much (if anything!) over the strcmp(). For each method, we'd have to
> call into the API to say "is it <this> one?" or "is it <that> one?"
> I'm going to have to look into this whole method registration thing. I saw
> it go in, but never bothered looking too closely. It didn't seem like it
> was going to monkey with the method number stored in the request. Eek.

The point was to allow modules to be able to associate a number with a
method that the core server didn't know anything about. In order to do that,
we did need to change the number.

> Dunno that the method stuff must change. At a minimum, mod_dav can just
> pre-register everything and keep the numbers around for use in the above
> logic. But I still want to get a look at the stuff and see what's there.
> I've got some particular experience with extended methods :-)

That was the original idea. Modules would register the method at startup,
and compare against that number, which is what the API's do.


Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:48 2006

This is an archived mail posted to the Subversion Dev mailing list.