httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] DAV method registration
Date Tue, 01 Oct 2002 17:50:51 GMT
On Mon, Sep 30, 2002 at 10:18:14PM -0700, Ryan Morgan wrote:
> On Mon, Sep 30, 2002 at 07:04:49PM -0700, Greg Stein wrote:
> > On Mon, Sep 30, 2002 at 05:35:40PM -0700, Ryan Morgan wrote:
> > >...
> > > This patch moves all the DAV method registration into the mod_dav module
> > > from the http core.  I'd like to do this for a couple reasons:
> > > 
> > > 1) It makes more sense to register these methods from the same module
> > >    they are used in.
> > 
> > mod_dav is (currently) an optional module. However, those methods are
> > defined within RFC standards. They apply to everything.
> Maybe I don't understand how DAV works, but how do the DAV methods apply
> if the mod_dav module is not loaded?

Other modules could handle those. Nothing gives mod_dav any more right to
them than anybody else :-)  (of course, nobody else has felt inclined to
write such an alternative)

> The behavior of the server does not
> change (when mod_dav is not loaded) for requests with those methods.

Actually, it does :-)  If the method is known, then it returns 405 (Method
Not Allowed). Otherwise, it returns 501 (Method Not Implemented).

Those methods are defined by an RFC, so we can/should include them in our
server. The server can *know* about them, but just declare that they aren't
allowed on the particular resource.

> > If you're going to have slots, then use them for standard methods. At the
> > moment, those are the DAV methods. If/when we see an explosion of other
> > methods, and the space getting crowded, *then* we can move them.
> Since Apache2 has the ability to serve multiple protocols, so the number of
> registered methods can grow quite rapidly. Since the HTTP module cannot 
> be removed from the server (without some serious effort.. ask rbb), the next 
> best thing is to not register those DAV methods if they will not be used by 
> the server.

HTTP methods are not going to be used for non-HTTP protocols, so I don't see
how this applies.

> The ideal solution would be to do away with the allow_methods bitmask
> altogether for something that does not have the 62 method limitation.
> This is also quite difficult, since much of the server relies on this
> being a bitmask.

On this part, I very much agree with you :-)

In general, our allow_methods processing is *very* ill-defined (maybe it is,
but it doesn't feel quite "there" to me; mod_dav interacts with it as well
as it can, but still...). A revamp to simply get it all cleaned up is in
order. When the allow_methods stuff was built, that was long before DAV was

> > > This patch also fixes a bug where DAV's BIND and SEARCH methods were being
> > > registered with the core twice, since post_config gets called twice.
> > > I have put in a check so that the methods only get registered once.
> > 
> > Barely a bug. The core returns the same number for the second registration.
> True, the function will not register the same method twice, but what about
> the case where mod_dav is the first to register a method?  The pool that gets
> passed in (pconf) will get cleared on the second run.  On the first call
> this is the pool that will be used to create the method hash. (this is 
> the hash used for subsequent calls to ap_method_register)

Um... so? If the pool is cleared, then the hash is cleared, too. Later
registrations will go into the new pool.

There is potentially a bug if the hash is created from a different pool than
the one passed to each method registration. We might want to use
apr_hash_pool() inside the method stuff, rather than using the passed pool.


Greg Stein,

View raw message