[
https://issues.apache.org/jira/browse/VFS-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425753#comment-13425753
]
Gary D. Gregory commented on VFS-428:
-------------------------------------
I can see the root cause from your last post. I did not try the set up.
It looks like the HttpClient 3.1 implementation is correct. I read this Javadoc
in
{{org.apache.commons.httpclient.methods.EntityEnclosingMethod.setFollowRedirects(boolean)}}:
{quote}
Entity enclosing requests cannot be redirected without user intervention
according to RFC 2616.
{quote}
In RFC 2616, section 10.3.2, I read:
{quote}
If the 301 status code is received in response to a request other than GET or
HEAD, the user agent MUST NOT automatically redirect the request unless it can
be confirmed by the user, since this might change the conditions under which
the request was issued.
{quote}
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3
When I look at JackRabbit 1.6.5 (the WebDAV library VFS uses), I see a that JR
uses a class called org.apache.jackrabbit.webdav.client.methods.PropFindMethod.
This is a custom JR WebDAV class.
This explains the failure because it is neither an HTTP GET or HEAD.
I'm not sure what to do here. There are many newer versions of JR available but
I've not upgraded VFS because JR no longer delivers an all-in-one jar.
You could try to use the current version of JR and see what happens. This may
require changes to code and will certainly need some changes to the VFS POM.
> DavException: (301) Moved Permanently
> --------------------------------------
>
> Key: VFS-428
> URL: https://issues.apache.org/jira/browse/VFS-428
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0, 2.1
> Environment: Apache 2.2.22 as Testerver and setted up like
> http://commons.apache.org/vfs/testserver.html (but changed the 'crypt'
> password)
> Reporter: Robert Kornmesser
> Priority: Blocker
> Labels: webdav
>
> Running the WebdavProviderTestCase using mvn -P webdav clean test
> -Dtest.webdav.uri=webdav://vfsusr:vfstest@localhost/vfstest
> -Dtest=WebdavProviderTestCase results in
> {code}DavException: (301) Moved Permanently
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.645 sec <<<
> FAILURE!
> Results :
> Tests in error:
>
> junit.framework.TestSuite@55c9be00(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1):
> Could not determine the type of file
> "webdav://vfsusr:****@localhost/vfstest/read-tests".
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> {code}
> The deeper Problem is, that the HttpClient using by VFS does not append a
> trailing slash and mod_dir of httpd has "DirectorySlash On" per default. So
> httpd send 301 redirect to the same url with / appended.
> I know that for this reason of problematic webdav client apache introduced
> "redirect-carefully" for some user agents using the "BrowserMatch" directive.
> So I just tried adding the following into my <Directory> directive
> {code}
> BrowserMatch "^Jakarta-Commons-VFS" redirect-carefully
> BrowserMatch "^Jakarta Commons-HttpClient/3.0" redirect-carefully
> BrowserMatch "^Jakarta Commons-HttpClient/3.1" redirect-carefully
> {code}
> Its needed to have Jakarta-Commons-VFS *and* Jakarta Commons-HttpClient
> because of two requests from commons vfs using two different user agents.
> But instead of solving the issue, I get for every FileObject.getChildren()
> call at least one FileObject of type imaginary with the same basename as the
> parent. Thats not a problem at all (besides that this is totally wrong!) but
> deleting a parent just dont work anymore, because of an *non-existent*
> imaginary file inside the dir which cannot be deleted of course.
> To cut a long story short, what is the right httpd webdav server config to
> use 2.0 Release version of VFS?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
