Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Feature request: Add 'content' field in -w %{json} output
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>
Date: Tue, 22 Feb 2022 08:40:25 +0100 (CET)
On Tue, 22 Feb 2022, rs _ via curl-users wrote:
> I think it would be quite useful to also have an additional field for the
> raw content of the response (which is already part of stdout and stderr.)
I'd call that the contents ot the content-type response header.
This is already in my longer term plan, sort of. But as a slightly larger
take.
1. We're discussing [A] a new API for libcurl for an easier way for
applications to extract headers and their contents after and during a HTTP
transfer. I'm working a version two of that proposal pending, ready to post
any day now and I hope that will take the dicussion even further. Perhaps even
get cranking on a first implementation to try out.
2. Once we have a libcurl API for accessing arbitrary headers, it will be easy
to add a way to provide generic headers and header contents in json format in
the -w output.
3. As we could then include all or any headers in the output, the question is
probably if %{json} should automatically include all response headers or if
they should be selected somehow. I think I lean toward all of them.
[A] = https://github.com/curl/curl/discussions/8335
Date: Tue, 22 Feb 2022 08:40:25 +0100 (CET)
On Tue, 22 Feb 2022, rs _ via curl-users wrote:
> I think it would be quite useful to also have an additional field for the
> raw content of the response (which is already part of stdout and stderr.)
I'd call that the contents ot the content-type response header.
This is already in my longer term plan, sort of. But as a slightly larger
take.
1. We're discussing [A] a new API for libcurl for an easier way for
applications to extract headers and their contents after and during a HTTP
transfer. I'm working a version two of that proposal pending, ready to post
any day now and I hope that will take the dicussion even further. Perhaps even
get cranking on a first implementation to try out.
2. Once we have a libcurl API for accessing arbitrary headers, it will be easy
to add a way to provide generic headers and header contents in json format in
the -w output.
3. As we could then include all or any headers in the output, the question is
probably if %{json} should automatically include all response headers or if
they should be selected somehow. I think I lean toward all of them.
[A] = https://github.com/curl/curl/discussions/8335
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-02-22