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.
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: rs _ via curl-users <curl-users_at_lists.haxx.se>
Date: Tue, 22 Feb 2022 00:58:49 -0600
A few fields have been added to the output of --write-out %{json} in recent
versions, however, it is still unnecessarily difficult to parse basic
elements of the response. 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.) The json object would be completely parsable as
opposed to the current behavior:
> curl -w '%{json}' https://example.com
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
{"content_type":"text/html; charset=UTF-8",...
so it would look like this (depending on the specifics of the command, it
could also include headers):
{
"content_type": "text/html; charset=UTF-8",
"errormsg": null,
"exitcode": 0,
"filename_effective": null,
"ftp_entry_path": null,
"http_code": 200,
"content": "<!doctype html>\n<html>\n<head>\n <title>Example
Domain</title>\n\n <meta charset=\"utf-8\" />\n ... <p>This domain is
for use in illustrative examples in documents. You may use this\n domain
in literature without prior coordination or asking for permission.</p>\n
<p><a href=\"https://www.iana.org/domains/example\">More
information...</a></p>\n</div>\n</body>\n</html>\n"
...
}
and then this becomes possible:
> curl -w '%{json}' https://example.com | jq '{"ct": .content_type, "code":
.http_code, "title": .content |
match("<title>(.*)</title>").captures[0].string}'
{
"ct": "text/html; charset=UTF-8",
"code": 200,
"title": "Example Domain"
}
Let me know what you think.
Date: Tue, 22 Feb 2022 00:58:49 -0600
A few fields have been added to the output of --write-out %{json} in recent
versions, however, it is still unnecessarily difficult to parse basic
elements of the response. 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.) The json object would be completely parsable as
opposed to the current behavior:
> curl -w '%{json}' https://example.com
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
{"content_type":"text/html; charset=UTF-8",...
so it would look like this (depending on the specifics of the command, it
could also include headers):
{
"content_type": "text/html; charset=UTF-8",
"errormsg": null,
"exitcode": 0,
"filename_effective": null,
"ftp_entry_path": null,
"http_code": 200,
"content": "<!doctype html>\n<html>\n<head>\n <title>Example
Domain</title>\n\n <meta charset=\"utf-8\" />\n ... <p>This domain is
for use in illustrative examples in documents. You may use this\n domain
in literature without prior coordination or asking for permission.</p>\n
<p><a href=\"https://www.iana.org/domains/example\">More
information...</a></p>\n</div>\n</body>\n</html>\n"
...
}
and then this becomes possible:
> curl -w '%{json}' https://example.com | jq '{"ct": .content_type, "code":
.http_code, "title": .content |
match("<title>(.*)</title>").captures[0].string}'
{
"ct": "text/html; charset=UTF-8",
"code": 200,
"title": "Example Domain"
}
Let me know what you think.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-02-22