Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

404 response for HEAD request #7187

Closed
cyberduck opened this issue Apr 30, 2013 · 9 comments
Closed

404 response for HEAD request #7187

cyberduck opened this issue Apr 30, 2013 · 9 comments
Assignees
Labels
bug thirdparty Issue caused by third party webdav WebDAV Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

daf40e3 created the issue

We have been using Cyberduck 4.2.1 and 4.2.2 just fine with our WebDAV server. Upon upgrading to Cyberduck 4.3, we are unable to open a connection the our WebDAV server. In return we get a 404 error, not found.

I have actually tried this on two different WebDAV servers: the Apache Web Server and one included as part of Nuxeo. They both failed. The returned output on the failed Cyberduck screen is shown in the attached screen shot.

Needless to say, this is a seriously blocking problem unless there is some way to configure Cyberduck in 4.3 to work around the problem. Is there anything like that?


Attachments

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please post the transcript from the log drawer (Ctrl-L).

@cyberduck
Copy link
Collaborator Author

daf40e3 commented

I don't have any idea what a log drawer is. If Cyberduck has a log, I don't know about it (but would like to).

Examples of the access log from the Apache web server are as follows:

mediaconsole.pearsoncmg.com:2013_05_01:console1:access.log:192.251.134.5 - uhubewi [01/May/2013:15:52:09 -0400] "HEAD /mdc/dav/media/ HTTP/1.1" 404 - "-" "Cyberduck/4.3 (10948) (Windows 7/6.1) (x86)" 1686
mediaconsole.pearsoncmg.com:2013_05_01:console1:access.log:192.251.134.5 - uhubewi [01/May/2013:15:56:35 -0400] "HEAD /mdc/dav/media/ HTTP/1.1" 404 - "-" "Cyberduck/4.3 (10948) (Windows 7/6.1) (x86)" 1861
mediaconsole.pearsoncmg.com:2013_05_01:console1:access.log:192.251.134.5 - uhubewi [01/May/2013:15:56:39 -0400] "HEAD /mdc/dav/media/ HTTP/1.1" 404 - "-" "Cyberduck/4.3 (10948) (Windows 7/6.1) (x86)" 1822

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:2 billhuber01]:

I don't have any idea what a log drawer is. If Cyberduck has a log, I don't know about it (but would like to).

Yes, there is a log drawer where you can find the connection transcript.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:2 billhuber01]:

Examples of the access log from the Apache web server are as follows:

mediaconsole.pearsoncmg.com:2013_05_01:console1:access.log:192.251.134.5 - uhubewi [01/May/2013:15:52:09 -0400] "HEAD /mdc/dav/media/ HTTP/1.1" 404 - "-" "Cyberduck/4.3 (10948) (Windows 7/6.1) (x86)" 1686
mediaconsole.pearsoncmg.com:2013_05_01:console1:access.log:192.251.134.5 - uhubewi [01/May/2013:15:56:35 -0400] "HEAD /mdc/dav/media/ HTTP/1.1" 404 - "-" "Cyberduck/4.3 (10948) (Windows 7/6.1) (x86)" 1861
mediaconsole.pearsoncmg.com:2013_05_01:console1:access.log:192.251.134.5 - uhubewi [01/May/2013:15:56:39 -0400] "HEAD /mdc/dav/media/ HTTP/1.1" 404 - "-" "Cyberduck/4.3 (10948) (Windows 7/6.1) (x86)" 1822

  • If the path /mdc/dav/media/ to your web server is not valid, check your connection or bookmark settings. Change the path property which determines the initial working directory when connecting to the server.
  • If the path /mdc/dav/media/ is a valid resource, the server should not return a 404 response. Check that HEAD is an accepted method the server handles and returns a 200 response.

We have changed the check of valid authentication credentials in 4.3 that we first try a HEAD request that the server must acknowledge to know that we have valid authentication tokens before we issue a PROPFIND request to request the directory listing. See #7139.

@cyberduck
Copy link
Collaborator Author

daf40e3 commented

I still don't know where the content of the log drawer is. The only description is the following:

Choose View → Toggle Log Drawer (⌘-L) to open the log drawer. Events are only logged once the drawer is open.

Yes, I can click on View and Toggle Log Drawer, but I have no idea where any log output is. Where is it and exactly how do I look at it? Thank you.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

#7200 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

I have installed nuxeo-cap-5.6-tomcat locally for testing and can login with no issues.

HEAD /nuxeo/site/dav/ HTTP/1.1
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Cyberduck/4.3 (Mac OS X/10.8.3) (x86_64)
Authorization: Basic YW5vbnltb3VzOmN5YmVyZHVja0BleGFtcGxlLm5ldA==
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
WWW-Authenticate: Digest realm="NUXEO", qop="auth", nonce="MTM2NzU3Mjc4MzQ2MTowYzhjMjRjNTgxM2I3YzRiMzI5YTY2MzkxZjZmYzAxOA=="
Content-Type: text/html;charset=utf-8
Content-Length: 954
Date: Fri, 03 May 2013 09:03:02 GMT
HEAD /nuxeo/site/dav/ HTTP/1.1
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Cyberduck/4.3 (Mac OS X/10.8.3) (x86_64)
Authorization: Digest username="anonymous", realm="NUXEO", nonce="MTM2NzU3Mjc4MzQ2MTowYzhjMjRjNTgxM2I3YzRiMzI5YTY2MzkxZjZmYzAxOA==", uri="/nuxeo/site/dav/", response="b757d505e7859478824d974e90ec4c82", qop=auth, nc=00000001, cnonce="d5bf8d6bf4dbd055", algorithm="MD5"
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
WWW-Authenticate: Digest realm="NUXEO", qop="auth", nonce="MTM2NzU3Mjc4MzUyMTo2ZTMxZmZjYTAxMTVlMzQxYzQ2N2U5ZGU5ZDdiNWJlOA=="
Content-Type: text/html;charset=utf-8
Content-Length: 954
Date: Fri, 03 May 2013 09:03:02 GMT
HEAD /nuxeo/site/dav/ HTTP/1.1
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Cyberduck/4.3 (Mac OS X/10.8.3) (x86_64)
Authorization: Basic QWRtaW5pc3RyYXRvcjpBZG1pbmlzdHJhdG9y
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html
Content-Length: 0
Date: Fri, 03 May 2013 09:03:20 GMT
PROPFIND /nuxeo/site/dav/ HTTP/1.1
Depth: 1
Content-Type: text/xml; charset=utf-8
Content-Length: 99
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Cyberduck/4.3 (Mac OS X/10.8.3) (x86_64)
Authorization: Basic QWRtaW5pc3RyYXRvcjpBZG1pbmlzdHJhdG9y
HTTP/1.1 207 Multi-Status
Server: Apache-Coyote/1.1
Content-Type: application/xml
Content-Length: 1067
Date: Fri, 03 May 2013 09:03:20 GMT
PROPFIND /nuxeo/site/dav/Administrator/ HTTP/1.1
Depth: 1
Content-Type: text/xml; charset=utf-8
Content-Length: 99
Host: localhost:8080
Connection: Keep-Alive
User-Agent: Cyberduck/4.3 (Mac OS X/10.8.3) (x86_64)
Authorization: Basic QWRtaW5pc3RyYXRvcjpBZG1pbmlzdHJhdG9y
HTTP/1.1 207 Multi-Status
Server: Apache-Coyote/1.1
Content-Type: application/xml
Content-Length: 625
Date: Fri, 03 May 2013 09:03:24 GMT

I suppose this is a configuration issue.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

#7219 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

018994c commented

Here's a work-around for Apache, and a suggestion for Cyberduck.

Cyberduck version pre-4.3 would open a connection using the OPTIONS method on the directory. Apache worked well with that. Newer Cyberduck versions open a connection using the HEAD method on a directory, which leads to problem with some Apache installations.

If Apache is configured to provide an index file for the directory (using the Apache DirectoryIndex directive or the Options +Index directive) then a code 200 by the HEAD method on a direcotry, and Cyberduck 4.3+ works fine. If no index file is server for a directory, then some Apache versions/configurations return a 404 code, which Cyberduck 4.3+ takes as a failure. Other Apache versions/configurations return a 403 code, which Cyberduck 4.3+ handles fine.

If your Apache has the problem and returns code 404, which you can see in this Apache access log entry,
XXX.XXX.XXX.XXX - myuserj [11/Sep/2013:13:05:29 -0400] "HEAD /mysite/ HTTP/1.1" 404 - "-"
"Cyberduck/4.3.1 (Mac OS X/10.8.4) (i386)"
then you can get Cyberduck working by configuring DirectoryIndex and putting the appropriate index file in your directory (for example, index.html) or configure mod_index and Options +Index.

Also, it looks like Cyberduck could be modified to work again with such Apache installations by either reverting to the OPTIONS method when opening a connection, or handling the 404 return code the same way it handles the 403 return code.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug thirdparty Issue caused by third party webdav WebDAV Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants