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/
