Hi all
Ensure that you use the latest Zope version (at least latest 2.4.X from the CVS).
We'll try this when we can, but for now we have 2.4.3 deployed, and will have to work with it for a while until we can upgrade clients.
If the problem persists, use the WebDAVLogger product to get any additional debug information from the WebDAV protocol layer.
OK, I tried that, but unless I'm missing something, I'm afraid it doesn't help (see logs below). Is there anything I should look for? One thing I notice is that the local Zope answers the initial GET with a 401, while the tunneled Zope answers it with a 500 (see below). On a local Zope (which does prompt for authentication in 'feko_usa', as I would expect) nothing to do with authentication shows up in the WebDAV log at all, when I do this:: dav:/> open localhost:13800 Looking up hostname... Connecting to server... connected. Connecting to server... connected. dav:/> cd feko_usa Connecting to server... connected. dav:/feko_usa/> cat news.htm Displaying `/feko_usa/news.htm': Connecting to server... connected. Authentication required for Zope on server `localhost': Username: jean Password: (When I try that thru the ssh tunnel, the only difference is:: dav:!> open localhost:8888 Looking up hostname... Connecting to server... connected. Connecting to server... connected. [... snip ...] dav:/feko_usa/> cat news.htm Displaying `/feko_usa/news.htm': Connecting to server... connected. Failed: 500 Internal Server Error ). Here follow part of the logs of those actions. The WebDAV section is in response to 'cd feko_usa'. The section from Z2.log is the only trace of 'cat news.htm':: --------------------------------------------------------------------------- --- Response: Timediff: 0.1949 seconds HTTP/1.1 207 Multi-Status Server: Zope/(Zope 2.4.3 (binary release, python 2.1, linux2-x86), python 2.1.1, linux2) ZServer/1.1b1 Date: Tue, 16 Apr 2002 14:02:44 GMT Ms-Author-Via: DAV Content-Type: text/xml; charset="utf-8" Connection: close Date: Tue, 16 Apr 2002 14:02:44 GMT Content-Length: 640 <?xml version="1.0" encoding="utf-8"?> <d:multistatus xmlns:d="DAV:"> <d:response> <d:href>/feko_usa/</d:href> <d:propstat> <d:prop> <n:getcontentlength xmlns:n="DAV:"></n:getcontentlength> <n:getlastmodified xmlns:n="DAV:">Mon, 08 Oct 2001 10:37:37 GMT</n:getlastmodified> <n:displayname xmlns:n="DAV:">feko_usa</n:displayname> <n:resourcetype xmlns:n="DAV:"><n:collection/></n:resourcetype> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> <d:propstat> <d:prop> <n:executable xmlns:n="http://apache.org/dav/props/"/> </d:prop> <d:status>HTTP/1.1 404 Not Found</d:status> </d:propstat> </d:response> </d:multistatus> ==> var/Z2.log <== 127.0.0.1 - Anonymous [16/Apr/2002:16:02:44 +0200] "PROPFIND /feko_usa/ HTTP/1.1" 207 948 "" "cadaver/0.19.1 neon/0.18.3" 127.0.0.1 - Anonymous [16/Apr/2002:16:03:01 +0200] "GET /feko_usa/news.htm HTTP/1.1" 401 3543 "" "cadaver/0.19.1 neon/0.18.3" 127.0.0.1 - jean [16/Apr/2002:16:03:05 +0200] "GET /feko_usa/news.htm HTTP/1.1" 200 4233 "" "cadaver/0.19.1 neon/0.18.3" Here is the corresponding fragment of Z2.log on the remote machine:: 127.0.0.1 - Anonymous [16/Apr/2002:16:14:01 +0200] "PROPFIND /feko_usa/ HTTP/1.1" 207 948 "" "cadaver/0.19.1 neon/0.18.3" 127.0.0.1 - Anonymous [16/Apr/2002:16:14:21 +0200] "GET /feko_usa/news.htm HTTP/1.1" 500 4349 "" "cadaver/0.19.1 neon/0.18.3" I notice that on the local machine there are *two* requests for 'news.htm': the first one as Anonymous, which triggers the cadaver authentication prompt, and the next as 'jean', after authentication. In the forwarded case, the Zope server returns a 500 instead of a 401. It looks as though this might be the problem: if only Zope can tell cadaver '401', it should prompt. As it does from the root:: 127.0.0.1 - Anonymous [16/Apr/2002:16:25:34 +0200] "PROPFIND / HTTP/1.1" 207 931 "" "cadaver/0.19.1 neon/0.18.3" 127.0.0.1 - Anonymous [16/Apr/2002:16:25:38 +0200] "GET /index_html HTTP/1.1" 401 2659 "" "cadaver/0.19.1 neon/0.18.3" 127.0.0.1 - jean [16/Apr/2002:16:25:45 +0200] "GET /index_html HTTP/1.1" 200 1966 "" "cadaver/0.19.1 neon/0.18.3" I'll see whether the latest 2.4 also behaves like this when I have a chance. Thanks for all the help so far .. -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za