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

Change in behavior for --remote-header-name #13302

Open
morganwillcock opened this issue Apr 6, 2024 · 2 comments · May be fixed by #13484
Open

Change in behavior for --remote-header-name #13302

morganwillcock opened this issue Apr 6, 2024 · 2 comments · May be fixed by #13484

Comments

@morganwillcock
Copy link

I did this

Commit 75d79a4 seems to introduce a change in behavior where the filename used for the downloaded file may no longer be affected by the --remote-header-name option.

The easiest way to demonstrate the problem is to try downloading a file from Sourceforge:

curl -fLOJ https://sourceforge.net/projects/openofficeorg.mirror/files/4.1.15/README.md/download

I expected the following

Currently the filename used will be "download".

In older versions of Curl and with commit 75d79a4 reverted, the filename used will be "README.md". The issue was noticed due to CI workflows failing with the latest release of Curl, when downloading dependencies from Sourceforge.

This seems a significant change in behavior. Is it completely intentional?

curl/libcurl version

8.7.0-DEV (On commit de7b3e89218467159a7af72d58cea8425946e97d)

operating system

Debian 12.5
Linux hostname 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux

jay added a commit to jay/curl that referenced this issue Apr 6, 2024
- Use the content-disposition filename (server-specified filename) for
  non-2xx responses.

For example, a server may send a content-disposition filename header
with a redirect reply (3xx) but not with the final response (2xx).
Without this change curl would ignore the server's specified filename
and continue to use the filename extracted from the user-specified URL.

This is a partial revert of 75d79a4, which limited content-disposition
and etag header processing to 2xx response codes. There's no explanation
for why that was done.

Reported-by: Morgan Willcock

Fixes curl#13302
Closes #xxxx
@jay
Copy link
Member

jay commented Apr 6, 2024

Please try #13303

@morganwillcock
Copy link
Author

That does fix it. Thank you.

jay added a commit to jay/curl that referenced this issue Apr 26, 2024
- Parse etag and content-disposition headers for 3xx replies.

For example, a server may send a content-disposition filename header
with a redirect reply (3xx) but not with the final response (2xx).
Without this change curl would ignore the server's specified filename
and continue to use the filename extracted from the user-specified URL.

Prior to this change, 75d79a4 had limited etag and content-disposition
to 2xx replies only.

Reported-by: Morgan Willcock

Fixes curl#13302
Closes #xxxx
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants