Cyberduck Mountain Duck CLI

Opened 6 years ago

Closed 4 years ago

#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 (20)

comment:1 Changed 6 years ago by A Alvarezayllon

  • Description modified (diff)

comment:2 Changed 6 years ago by dkocher

  • Description modified (diff)

comment:3 Changed 5 years ago by dkocher

Previously in #3206.

comment:4 follow-up: Changed 5 years ago 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: Changed 5 years ago 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 5 years ago 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 5 years ago 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 5 years ago 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&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

Last edited 5 years ago by dkocher (previous) (diff)

comment:9 Changed 5 years ago by dkocher

  • Milestone changed from 4.4 to 4.5
  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:10 Changed 5 years ago by dkocher

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

comment:11 Changed 5 years ago 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

Last edited 5 years ago by dkocher (previous) (diff)

comment:12 Changed 5 years ago by dkocher

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

comment:13 follow-up: Changed 5 years ago 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 5 years ago 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 5 years ago 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 4 years ago 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 4 years ago 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 4 years ago by dkocher

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:19 Changed 4 years ago by dkocher

Added test in r14431.

comment:20 Changed 4 years ago by dkocher

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.
swiss made software