Context Navigation

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

Previously in #3206.

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&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 on Nov 28, 2013 at 8:05:15 AM by dkocher (previous) (diff)

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

Last edited on Nov 28, 2013 at 3:25:42 PM by dkocher (previous) (diff)

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: