Mark Thomas wrote:
On 22/06/2015 09:39, Mark Thomas wrote:
On 22/06/2015 00:25, Michael Salisbury wrote:
<snip/>
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.
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.
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.
I needed to enable directory listings otherwise I got a 'network name
not found' error 0x80070043.
With that one change I was able to map a Windows network drive to:
http://<ip-address>/
http://<ip-address>/test
http://<ip-address>:8080/
http://<ip-address>:8080/test
With https the behaviour is very strange. Windows is prompting me for
credentials even though none are required. I suspect that the untrusted
test certificate may be causing some of these problems.
I fixed the certificate problem so that IE viewed the site as trusted
and then I could map a network drive to:
https://<ip-address>/
https://<ip-address>/test
https://<ip-address>:8443/
https://<ip-address>:8443/test
No registry changes were required to get this to work.
Prompting for authentication in response to an untrusted certificate is
bizarre to say the least.
Microsoft generously provide MSDN subscriptions for Apache committers
which is why I have the various OS's to hand to test this. The
subscription also comes with tech support. I'll open an incident. It
will be interesting to see if things have improved since I last tried
raising bugs with Microsoft (I filed so many bugs with MS Office and it
took so long for MS to fix them that I hit the limit of issues MS would
let me have open in parallel).
I was testing with Windows 7, SP1, 64-bit, fully patched
None of my WebDAV endpoints are configured to require authentication.
I did not have to use the WebdavFixFilter.
Note that I do not have MS Office installed on this machine.
It does look like things have improved with more recent versions of the
Windows clients. I'm not sure what is causing the error you are seeing.
Maybe MS Office ships with a different WebDAV client.
From what I remember, yes it does. That is what I was referring to when talking about
"depending on what other software is installed on the workstation." As I recall, when
installing MS-office, it replaces the "mini-redirector" by its own DLL, and that changes
the behaviour in a number of instances.
From past
experience, I'd suggest trying some of the following:
- get it working over http before trying https
- get it working at the server root before trying just a context
- get it working without authentication before trying with authentication
- ensure you have directory listings enabled
- ensure that IE trusts any certificates and no certificate errors are
reported when connecting over https
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
