mod_dav behaviors

[Greg Stein <gs...@lyra.org>]

On Wed, Oct 02, 2002 at 09:28:51PM -0500, William A. Rowe, Jr. wrote:
>...
> Ryan and I spent literally an HOUR on the phone dissecting this issue.
> I don't have the brain cycles to fully dump that conversation back, but it
> comes down to this;
> 
> * No request except DAV methods should ever receive the DAV handler.

Heh. mod_dav also needs to handle GET and POST. Consider mod_dav_svn... the
GET is definitley handled by mod_dav :-)

But your general point is valid: mod_dav should not have set the handler if
it was not going to handle the request. For the POST case, mod_dav was never
intending to handle it -- only check the locks then return DECLINED for the
"real" handler to deal with it.

> * There must be a DAV handler registered run-very-first ... if the handler
>   is not DAV, yet there is a file, DAV checks the per-dir-config from the
>   request rec.  If DAV is ON, the request must be locked. 
> * If the lock fails, dav satisfies the request with a 'Resource Locked' 
>   response after some timeout.
> * If the lock is granted, register a cleanup to release the lock.

Euh... you misunderstand DAV locks. They are not per-request, but long-lived
items. Somebody issues a LOCK request. Sometime later, they issue an UNLOCK
request. In between those points, mod_dav needs to reject any POST
operations to the resource unless the correct authorization and locktoken
are present in the request.

>...
> We really need THREE pool scopes.  The Connection, The Response
> and The Request.  This way, the response can outlive the request by
> whatever time is needed to spool out the last of the sendfile fd or mmap
> or whatever other -transient- method is required.

Not sure how this relates to above, but I suspect from the mis-notion of
[DAV] locks on a resource.

In any case... Yup. This would be very cool, and will be very helpful when
we move to a model where we have a single thread multiplexing responses to
the clients.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/