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: HTTP response header access in curl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Thu, 17 Mar 2022 18:21:09 -0400
On 17-Mar-22 17:43, Daniel Stenberg via curl-users wrote:
> # HTTP response header access in curl
>
> This support depends on the new headers API work coming in PR 8593.
> Hopefully landing in 7.83.0.
>
> This new header output is done with -w and new magic added to its
> abilties.
>
> This is how it works right now. I'm showing it off early here because
> I like it and it gives everyone a chance to voice opinions about the
> approach.
>
> ## Output individual header contents
>
> Say hello to %header{name} where name is the case insensitive name of
> the header withon colon.
>
> $ curl -w '%header{date}\n' curl.se
> Thu, 17 Mar 2022 16:59:24 GMT hello
>
> ## Output all response headers as JSON
>
> Say hello to %{header_json}
>
> $ curl -sw '%{header_json}\n' curl.se | jq
> {
> "Server": "Varnish",
> "Retry-After": "0",
> "Location": "https://curl.se/",
> "Content-Length": "0",
> "Accept-Ranges": "bytes",
> "Date": "Thu, 17 Mar 2022 17:01:38 GMT",
> "Via": "1.1 varnish",
> "Connection": "close",
> "X-Served-By": "cache-bma1667-BMA",
> "X-Cache": "HIT",
> "X-Cache-Hits": "0",
> "X-Timer": "S1647536498.479515,VS0,VE0"
> }
>
>
In your example, you have the --output and the -w both going to stdout;
jq is ignoring the HTML.
This isn't guaranteed to work if the data looks like json - and is
wasteful since the data is ignored.
--output would put the html someplace else.
Not sure if this is simply a bad example (doc shouldn't use it), or if
-w without -o deserves a warning (which I guess would be a compatibility
issue), or the interactions need some thought. It's not exactly a new
issue, since the design decision on -w is old. But this seems to
highlight it.
Perhaps -w doc should advise that -o be considered when it's used.
Given where we are, there isn't a perfect/obvious answer. But at least
the doc should use a more sensible example.
%header{name} is a bit verbose if you want more than one. Perhaps
%header{name1:name2:...} might output selected headers, replacing the
':'s with \n?
Otherwise, seems reasonable.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2022-03-17
Date: Thu, 17 Mar 2022 18:21:09 -0400
On 17-Mar-22 17:43, Daniel Stenberg via curl-users wrote:
> # HTTP response header access in curl
>
> This support depends on the new headers API work coming in PR 8593.
> Hopefully landing in 7.83.0.
>
> This new header output is done with -w and new magic added to its
> abilties.
>
> This is how it works right now. I'm showing it off early here because
> I like it and it gives everyone a chance to voice opinions about the
> approach.
>
> ## Output individual header contents
>
> Say hello to %header{name} where name is the case insensitive name of
> the header withon colon.
>
> $ curl -w '%header{date}\n' curl.se
> Thu, 17 Mar 2022 16:59:24 GMT hello
>
> ## Output all response headers as JSON
>
> Say hello to %{header_json}
>
> $ curl -sw '%{header_json}\n' curl.se | jq
> {
> "Server": "Varnish",
> "Retry-After": "0",
> "Location": "https://curl.se/",
> "Content-Length": "0",
> "Accept-Ranges": "bytes",
> "Date": "Thu, 17 Mar 2022 17:01:38 GMT",
> "Via": "1.1 varnish",
> "Connection": "close",
> "X-Served-By": "cache-bma1667-BMA",
> "X-Cache": "HIT",
> "X-Cache-Hits": "0",
> "X-Timer": "S1647536498.479515,VS0,VE0"
> }
>
>
In your example, you have the --output and the -w both going to stdout;
jq is ignoring the HTML.
This isn't guaranteed to work if the data looks like json - and is
wasteful since the data is ignored.
--output would put the html someplace else.
Not sure if this is simply a bad example (doc shouldn't use it), or if
-w without -o deserves a warning (which I guess would be a compatibility
issue), or the interactions need some thought. It's not exactly a new
issue, since the design decision on -w is old. But this seems to
highlight it.
Perhaps -w doc should advise that -o be considered when it's used.
Given where we are, there isn't a perfect/obvious answer. But at least
the doc should use a more sensible example.
%header{name} is a bit verbose if you want more than one. Perhaps
%header{name1:name2:...} might output selected headers, replacing the
':'s with \n?
Otherwise, seems reasonable.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature