Opened on Mar 14, 2012 at 2:39:26 PM
Closed on Mar 26, 2014 at 2:46:22 PM
Last modified on Oct 5, 2019 at 9:00:26 PM
#6586 closed enhancement (fixed)
Follow redirects on PUT
Reported by: | A Alvarezayllon | Owned by: | dkocher |
---|---|---|---|
Priority: | normal | Milestone: | 4.4.4 |
Component: | webdav | Version: | 4.2.1 |
Severity: | normal | Keywords: | |
Cc: | Architecture: | ||
Platform: |
Description (last modified by dkocher)
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.
Change History (22)
comment:1 Changed on Mar 14, 2012 at 2:42:28 PM by A Alvarezayllon
- Description modified (diff)
comment:2 Changed on Mar 15, 2012 at 10:38:12 AM by dkocher
- Description modified (diff)
comment:3 Changed on Sep 18, 2013 at 10:29:08 AM by dkocher
comment:4 follow-up: ↓ 5 Changed on Sep 18, 2013 at 3:18:30 PM by dkocher
- Milestone set to 4.4
- Resolution set to fixed
- Status changed from new to closed
Set preference webdav.redirect.PUT.follow using defaults write ch.sudo.cyberduck webdav.redirect.PUT.follow true as of r12989.
comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed on Nov 25, 2013 at 8:50:08 AM by antonio calanducci
Replying to dkocher:
Set preference webdav.redirect.PUT.follow using defaults write ch.sudo.cyberduck webdav.redirect.PUT.follow true as of r12989.
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
comment:6 in reply to: ↑ 5 Changed on Nov 25, 2013 at 2:08:53 PM by dkocher
Replying to antonio calanducci:
Replying to dkocher:
Set preference webdav.redirect.PUT.follow using defaults write ch.sudo.cyberduck webdav.redirect.PUT.follow true as of r12989.
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.
comment:7 Changed on Nov 25, 2013 at 4:48:16 PM by antonio calanducci
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.
comment:8 Changed on Nov 25, 2013 at 4:56:08 PM by antonio calanducci
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&dpmtoken=3d056a5a-436e-4 dd8-86b7-9787c0313d9a&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
comment:9 Changed on Nov 25, 2013 at 9:57:43 PM by dkocher
- Milestone changed from 4.4 to 4.5
- Resolution fixed deleted
- Status changed from closed to reopened
comment:10 Changed on Nov 28, 2013 at 1:02:11 PM by dkocher
Please update to the latest snapshot build available and let me know if it makes a difference.
comment:11 Changed on Nov 28, 2013 at 3:04:18 PM by antonio calanducci
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
comment:12 Changed on Nov 28, 2013 at 3:25:26 PM by dkocher
Thanks for the comment. We will need to add tests.
comment:13 follow-up: ↓ 14 Changed on Nov 28, 2013 at 4:03:54 PM by 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?
comment:14 in reply to: ↑ 13 Changed on Nov 28, 2013 at 4:10:28 PM by dkocher
Replying to 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
comment:15 Changed on Nov 28, 2013 at 4:32:22 PM by antonio calanducci
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?
comment:16 Changed on Feb 5, 2014 at 4:39:48 PM by dkocher
- Milestone changed from 4.5 to 4.4.4
- Resolution set to fixed
- Status changed from reopened to closed
Fix repeated PUT in r14303.
comment:17 Changed on Mar 18, 2014 at 5:53:08 PM by antonio calanducci
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
comment:18 Changed on Mar 19, 2014 at 5:35:39 PM by dkocher
- Resolution fixed deleted
- Status changed from closed to reopened
comment:19 Changed on Mar 26, 2014 at 2:46:08 PM by dkocher
Added test in r14431.
comment:20 Changed on Mar 26, 2014 at 2:46:22 PM by dkocher
- Resolution set to fixed
- Status changed from reopened to closed
comment:21 follow-up: ↓ 22 Changed on May 4, 2019 at 7:00:59 PM by steffend
Why is this option not enabled by default?
comment:22 in reply to: ↑ 21 Changed on Oct 5, 2019 at 9:00:26 PM by firelord
Replying to 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.
Previously in #3206.