-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
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
Labels
Comments
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
Please try #13303 |
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
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:
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
The text was updated successfully, but these errors were encountered: