[
https://issues.apache.org/jira/browse/VFS-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304966#comment-14304966
]
Bernd Eckenfels commented on VFS-560:
-------------------------------------
Can you please include the exception stack trace? Are you using URL, http or
webdav provider (are you using the default configured VFS.getManager()?)
It looks like the HTTP Provider does an initial head request when the
filesystem is initialized to check basic connectivity. It looks like this cant
be turned off (and you can also not disable redirect chasing). I guess a quick
fix for you might be to use the URLFileProvider instead.
I am not sure what would be better, making this configurable or just plain
removing it.
> File can't be downloaded if HTTP HEAD on base url fails
> -------------------------------------------------------
>
> Key: VFS-560
> URL: https://issues.apache.org/jira/browse/VFS-560
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Patrick GH
>
> When i try to download a File via HTTP a HEAD-Request on the base url is
> executed before the actual download. In my case the result is a redirect
> (HTTP 302) to another server. This server is not available due to firewall
> restrictions and so the following HEAD request fails. The actual GET request
> to retrieve the file is never performed.
> Example:
> Url: http://server1.com/files/2015/image.jpg
> 1. commons-vfs sends HEAD request to http://server1.com/ (not
> http://server1.com/files/2015/image.jpg)
> 2. Server returns HTTP 302 with redirect to http://server2.com/
> 3. commons-vfs sends HEAD request to http://server2.com/
> 4. Request fails because server2.com is not available (firewall)
> 5. image.jpg is not downloaded
> Why is this HEAD request on the base url necessary? The file can be
> downloaded directly without problems.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
