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

Follow redirects on PUT #6586

Closed
cyberduck opened this issue Mar 14, 2012 · 17 comments
Closed

Follow redirects on PUT #6586

cyberduck opened this issue Mar 14, 2012 · 17 comments
Assignees
Labels
enhancement fixed webdav WebDAV Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

0681515 created the issue

From HTTP/1.1 RFC (2616):

The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD.

Which does not discard the option of following the redirect after the users agrees.

Since we give support to a DAV implementation that does redirects on PUT's, this would be a really nice-to-have feature.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Previously in #3206.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Set preference webdav.redirect.PUT.follow using defaults write ch.sudo.cyberduck webdav.redirect.PUT.follow true as of 3ee521e.

@cyberduck
Copy link
Collaborator Author

38fc8ae commented

Replying to [comment:4 dkocher]:

Set preference webdav.redirect.PUT.follow using defaults write ch.sudo.cyberduck webdav.redirect.PUT.follow true as of 3ee521e.

Hi,

is this change already been in production? I am using the latest 4.4.2 (OS X Mavericks) setting the preference as you suggested, but it seems that it cannot follow the redirect in a PUT request. Is the 307 Temporary Redirect supported, via Location header?

thanks

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:5 antonio calanducci]:

Replying to [comment:4 dkocher]:

Set preference webdav.redirect.PUT.follow using defaults write ch.sudo.cyberduck webdav.redirect.PUT.follow true as of 3ee521e.

Hi,

is this change already been in production? I am using the latest 4.4.2 (OS X Mavericks) setting the preference as you suggested, but it seems that it cannot follow the redirect in a PUT request. Is the 307 Temporary Redirect supported, via Location header?

thanks

Yes, this is supposed to be fixed with the hidden setting.

@cyberduck
Copy link
Collaborator Author

38fc8ae commented

Using mitmproxy to look what happens at the client side, I see that redirection URI in the Location header is sent back from the server, but Cyberduck client doesn't try to follow it.
Is there a way to enable HTTP debug logging on Cyberduck to see what happens? Setting ch.sudo.cyberduck logging to debug, doesn't write any HTTP traffic log to the console.

@cyberduck
Copy link
Collaborator Author

38fc8ae commented

here the response from the server:

2013-11-25 17:51:55 PUT http://glibrary.ct.infn.it/dm/dav/vo.dch-rp.eu/prod-se-03.ct.infn.it/dpm/ct.infn.it/
                        home/vo.dch-rp.eu/deroberto/pippo/demo.jpg
                        <- 307 text/html 572B 158.57kB/s
Request                                               Response
Date:            Mon, 25 Nov 2013 16:51:58 GMT
Server:          Apache/2.2.3 (Scientific Linux)
vary:            Accept-Encoding
Content-Length:  572
location:        http://prod-se-03.ct.infn.it/storage/vo.dch-rp.eu/2013-11-25/demo.jpg.576.0?sfn=%2Fdpm%2Fct
                 .infn.it%2Fhome%2Fvo.dch-rp.eu%2Fderoberto%2Fpippo%2Fdemo.jpg&dpmtoken=3d056a5a-436e-4dd8-8
                 6b7-9787c0313d9a&token=dz%2BeQ%2B73TsToYtYxXTKG0dByrW8%3D%401385399340%401
Connection:      close
Content-Type:    text/html; charset=iso-8859-1
HTML
<!DOCTYPE html PUBLIC "_IETF_DTD HTML 2.0//EN">
<html>
  <head>
    <title>307 Temporary Redirect</title>
  </head>
  <body>
<h1>Temporary Redirect</h1>
<p>The document has moved <a href="http://prod-se-03.ct.infn.it/storage/vo.dch-rp.eu/2013-11-25/demo.jpg.576
.0?sfn=%2Fdpm%2Fct.infn.it%2Fhome%2Fvo.dch-rp.eu%2Fderoberto%2Fpippo%2Fdemo.jpg&amp;dpmtoken=3d056a5a-436e-4
dd8-86b7-9787c0313d9a&amp;token=dz%2BeQ%2B73TsToYtYxXTKG0dByrW8%3D%401385399340%401">here</a>.</p>
<hr/><address>Apache/2.2.15 (Scientific Linux) Server at prod-se-03.ct.infn.it Port 443</address>
</body>
</html>

after this, cyberduck pop up a dialog with:

Upload failed (/dm/dav/vo.dch-rp.eu/prod-se-03.ct.infn.it/dpm/ct.infn.it/home/vo.dch-rp.eu/deroberto/pippo/demo.jpg).
TEMPORARY REDIRECT.

Choosing continue doesn't sort any effect.

thanks

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please update to the latest snapshot build available and let me know if it makes a difference.

@cyberduck
Copy link
Collaborator Author

38fc8ae commented

Unfortunately nothing changed. Still getting the "TEMPORARY REDIRECT." message in a pop up dialog. Inspecting the HTTP traffic on the client side, I see that the PUT request returns a 307 stutus with the proper Location header, but no other following PUT request to the returned URL.
I am using Version 4.4.3 (14137), is this the latest snapshot or am I using the wrong version?
I have also this set to my defaults:

$ defaults read ch.sudo.cyberduck | grep webdav
    "webdav.redirect.PUT.follow" = true;

best
Antonio

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Thanks for the comment. We will need to add tests.

@cyberduck
Copy link
Collaborator Author

38fc8ae commented

I have noticed that our WebDAV server doesn't not return the 100-continue status code to the cyberduck client, but receive all the body and return the 307 redirection. It this maybe the reason why cyberduck won't follow the redirect? Is the Expect 100 header involved in the handshake?

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:13 antonio calanducci]:

I have noticed that our WebDAV server doesn't not return the 100-continue status code to the cyberduck client, but receive all the body and return the 307 redirection. It this maybe the reason why cyberduck won't follow the redirect? Is the Expect 100 header involved in the handshake?

Yes, If your server does not implement expectation (see also #7642) correctly that could very well be the cause. Try to disable the expectation handshake with the property webdav.expect-continue.

defaults write ch.sudo.cyberduck webdav.expect-continue false

@cyberduck
Copy link
Collaborator Author

38fc8ae commented

ok. I will try to implement the 100-continue response, but I tried your workaround. I see that cyberduck doesn't send anymore the Expect header, but it doesn't follow anyway the redirect :( Disabling expectation through properties, it is supposed to resend the body to the redirect url?
Is there a way to enable a verbose http debug log on cyberduck to see if some error occurs?

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Fix repeated PUT in 9ec6be5.

@cyberduck
Copy link
Collaborator Author

38fc8ae commented

Hi,

I have just downloaded the latest nightly builds (4.4.4 14382) and now setting the "webdav.redirect.PUT.follow" = true" hidden properties, PUT redirects are followed!
Anyway, it still doesn't work properly cause the body is completely sent during the first PUT request, while it should be sent only to the redirect URL (it sends 0 byte to the redirect, it should be the way around). I have also noticed that the client doesn't send anymore the Expect:100-continue header by default (and even if I set the "webdav.expect-continue" = true, it doesn't send this header).


Just to be clearer, I expect the workflow of the request should be:

  • cyberduck send a PUT request to the server, but holding for sending the body data (raw data)
  • the server returns a 307 redirect URL to the client
  • the client follow the redirect URL sending the raw data to the redirect URL returned by the server

Am I wrong?
Thank you

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Added test in addf3ff.

@cyberduck
Copy link
Collaborator Author

f52f3d3 commented

Why is this option not enabled by default?

@cyberduck
Copy link
Collaborator Author

d5570da commented

Replying to [comment:21 steffend]:

Why is this option not enabled by default?

I second this: At sciencedata.dk we have a distributed webdav setup and it would be really nice to not have to ask users to change hidden settings. This too goes for webdav.redirect.MKCOL.follow, webdav.redirect.DELETE.follow and webdav.redirect.MOVE.follow.

@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
enhancement fixed webdav WebDAV Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants