Mark Thomas wrote:
On 22/06/2015 00:25, Michael Salisbury wrote:
Thanks, I've done much searching - hence why I'm finally posting here.
Windows WebDAV is actually quite reasonable
Many people would disagree with that statement. It hasn't been updated
since the early days of Windows 7 but this site gives you an idea of
just what a disaster the Windows WebDAV client has been:
http://greenbytes.de/tech/webdav/webdav-redirector-list.html
It is possible that things have improved in the last few years but the
fact that Tomcat's WebDAV implementation works with a bunch of standards
compliant clients and only fails with the Windows client suggests that
the Windows client still has some issues.
- a lot of what one reads on the internet is because people don't know how to
configure it. It won't pass basic authentication across a connection by
default, you have to turn it on and there are two different settings for
allowing it over SSL only or a non-encrypted connection.
When connecting from a Windows client (any Windows client) I get a 'network
path not found' error 0x80070035. I know the path is valid as I can reach it
via other means, and other WebDAV clients.
A good example of the idiosyncracies of the Windows webDAV client : re-enter the same URL,
but specifiy the ":port" after the server name (even if it is 80).
On some Windows configurations, when not specifying the port, it tries to map this to a
"Windows share URL", à la "\\servername\sharename", leading to the error above.
My earlier comments were meant in a practical sense. We provide document-management
applications, where one of the ways in which a user can file a document into the system is
via DAV drag-and-drop directories.
We have spent a lot of time trying to debug these issues, to finally come to the
conclusion that the only way to insure consistent behaviour among customers who may have
different versions of Windows and different software installed on their PCs (sometimes on
a PC-by-PC base), was to recommend that they use one of these external WebDav clients.
Your situation may be different, and you might be able to enforce some specific Windows
version, and/or some specific Registry settings. We could not do that, hence our solution.
I was just trying to potentially save you a lot of hassle and loss of time.
I don't know if in your case it is practical and/or business-effective to use an
additional webDav client, but if it is possible, that would still be my recommendation.
Since we do that, we have 0 problems in that area. Before we did that, we had several
related support calls per week. Your call.
The main reason I think this is a Tomcat issue is that it was working just fine
with v7.0 and no other Windows client changes (updates, software etc.) have
been made. There wasn't anything specific in the Tomcat7 config that I needed
to get the MS client to work, only on the client itself those registry changes
as previously mentioned.
Not to make this a rant or a flame, but the same issues as described on the greenbytes
page mentioned above, also happen with other server-side DAV implementations, such as
Apache httpd. So it is not really a Tomcat-only issue.
What about the WebdavFixFilter? Is it configured in Tomcat 7 but not 8?
I'll run a Wireshark trace and see what comes up, nothing in the Tomcat logs
that I can see...
I'll do a quick test now and see what I can come up with.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
