Re: cvs commit: cocoon-2.1/src/blocks/webdav/java/org/apache/cocoon/components/source/impl WebDAVSource.java
Gianugo Rabellino wrote: Guido Casper wrote: Gianugo Rabellino wrote: [EMAIL PROTECTED] wrote: gcasper 2003/12/17 05:42:14 Modified: src/blocks/webdav/java/org/apache/cocoon/components/source/impl WebDAVSource.java Log: Interoperability with mod_dav Why so? I think that the cleanest way is to solve this issue where it belongs, inside httpclient if possible, or in httpd, with a BrowserMatch directive... How do you solve that with a BrowserMatch directive? If that is possible I revert the change. BrowserMatch ^Jakarta Commons-HttpClient redirect-carefully Redirect (assuming you mean rewrite) what? How to find out what is a collection and what not? mod_dav sends a redirect on collections without a trailing slash. And it's disputable which one is the correct behaviour. I tend to think that Apache does it right... IIUC the correct behaviour is to just send the response together with a Location header so that the WebDAV client adjusts its base URL for further requests. But since clients tend to ignore that header some server send a redirect instead. So what mod_dav does is considered well behaved and to be expected with other servers as well. Unfortunately this breaks WebDAVSource with TraversableSourceDescriptionGenerator. I just tried setting followRirects in WebDAVResource.propfindMethod without success :-( . The only other places to fix this is either WebDAVSource or WebDAVResource.setWebdavProperties/.processProperty. httpclient reasonably doesn't modify the set URL in any way. If you prefer I could ask slide-dev to change WebDAVResource to set followRedirects on propfind requests (I didn't test that yet and somewhat fear the performance penalty). You think so? Why should there be a performance penalty? Because of doubling the number of roundtrips. The problem only shows with TraversableSourceDescriptionGenerator on collections containing child collections. It's the only one doing a getSourceProperties (propfind) on child collections. One propfind (and a redirect since their URL doesn't contain the trailing slash) on each child collection. And if the number of child collection is big ... Guido
Re: cvs commit: cocoon-2.1/src/blocks/webdav/java/org/apache/cocoon/components/source/impl WebDAVSource.java
Gianugo Rabellino wrote: [EMAIL PROTECTED] wrote: gcasper 2003/12/17 05:42:14 Modified: src/blocks/webdav/java/org/apache/cocoon/components/source/impl WebDAVSource.java Log: Interoperability with mod_dav Why so? I think that the cleanest way is to solve this issue where it belongs, inside httpclient if possible, or in httpd, with a BrowserMatch directive... How do you solve that with a BrowserMatch directive? If that is possible I revert the change. mod_dav sends a redirect on collections without a trailing slash. httpclient reasonably doesn't modify the set URL in any way. If you prefer I could ask slide-dev to change WebDAVResource to set followRedirects on propfind requests (I didn't test that yet and somewhat fear the performance penalty). Guido
Re: cvs commit: cocoon-2.1/src/blocks/webdav/java/org/apache/cocoon/components/source/impl WebDAVSource.java
Guido Casper wrote: Gianugo Rabellino wrote: [EMAIL PROTECTED] wrote: gcasper 2003/12/17 05:42:14 Modified: src/blocks/webdav/java/org/apache/cocoon/components/source/impl WebDAVSource.java Log: Interoperability with mod_dav Why so? I think that the cleanest way is to solve this issue where it belongs, inside httpclient if possible, or in httpd, with a BrowserMatch directive... How do you solve that with a BrowserMatch directive? If that is possible I revert the change. BrowserMatch ^Jakarta Commons-HttpClient redirect-carefully mod_dav sends a redirect on collections without a trailing slash. And it's disputable which one is the correct behaviour. I tend to think that Apache does it right... httpclient reasonably doesn't modify the set URL in any way. If you prefer I could ask slide-dev to change WebDAVResource to set followRedirects on propfind requests (I didn't test that yet and somewhat fear the performance penalty). You think so? Why should there be a performance penalty? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: cvs commit: cocoon-2.1/src/blocks/webdav/java/org/apache/cocoon/components/source/impl WebDAVSource.java
[EMAIL PROTECTED] wrote: gcasper 2003/12/17 05:42:14 Modified:src/blocks/webdav/java/org/apache/cocoon/components/source/impl WebDAVSource.java Log: Interoperability with mod_dav Why so? I think that the cleanest way is to solve this issue where it belongs, inside httpclient if possible, or in httpd, with a BrowserMatch directive... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
