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
header api: add curl_easy_header and curl_easy_nextheader #8593
Conversation
does this cover 100 status responses, for example HTTP/1.1 101 Switching Protocols |
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment was marked as outdated.
This comment was marked as outdated.
1f8b020
to
ebdd863
Compare
This comment has been hidden.
This comment has been hidden.
Add test 1940 to 1946 to verify. Closes #8593
Add test 1940 to 1946 to verify. Closes #8593
Add test 1940 to 1946 to verify. Closes #8593
Add test 1940 to 1946 to verify. Closes #8593
I'm ready to merge this within the next few days. Any comments to take into account before that happens? |
Add test 1940 to 1946 to verify. Closes #8593
Outputs the response header 'name'
Outputs all response headers as a JSON object.
Defaults to disabled while labeled EXPERIMENTAL. Make all the headers API tests require 'headers-api' to run.
Hmm, was this supposed to hide the new experimental ABI by default if --enable-headers-api is not given? Because it doesn't seem it does. |
Can you clarify what you're asking? |
This post clearly states that these new functions should not be exposed as they are experimental. Yet it looks based on our ABI checks that they are indeed exposed by default even without the flag to expose them https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/2386983527 Is this intended behaviour or should I file a bug? |
The functions are present even when disabled, but they don't do anything. They have no functionality. |
I see. But just exposing them means people may call them. As it was said, the ABI is subject to change up to function signatures so isn't it completely unsafe to keep them there even as no-op functions? |
Why would someone call them if they don't do anything? And yes, providing experimental features risks that users don't read our warnings and go ahead and use them anyway. I don't see an easy way to prevent that. |
Couldn't you just use USE_HEADERS_API macro to hide them as private symbols? |
On Thu, Apr 28, 2022 at 02:34:37PM -0700, Daniel Stenberg wrote:
Why would someone call them if they don't do anything?
In an application in the year 2024 uses the functions then someone downgrades
the library or runs the binary on CentOS with an old libcurl, it would silently
fail instead of raising a run-time dynamic link error.
|
Early docs: https://github.com/curl/curl/wiki/get-headers-v2
curl_easy_header
curl_easy_header
with CONNECTcurl_easy_header
with 1xxcurl_easy_header
with trailerscurl_easy_header
in a redirect casecurl_easy_nextheader
curl -w
to output header contents with%header{name}
-w %{header_json}
- ouputs all headers as JSON-w %{header_json}
handle duplicate headers-w %header{name}
-w %{header_json}
Remove the wiki page (to keep the docs in a single place) after initial merge