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: An API for extracing (HTTP) headers?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Tue, 22 Mar 2022 06:47:09 -0400
On 22-Mar-22 04:01, Daniel Stenberg via curl-library wrote:
> On Tue, 15 Mar 2022, Daniel Stenberg via curl-library wrote:
>
>> - https://github.com/curl/curl/pull/8593
>
> I merged the headers API as experimental.
>
> On the blog:
> https://daniel.haxx.se/blog/2022/03/22/a-headers-api-for-libcurl/
>
Some observations from reading the man pages:
* Both man pages : the header "extract a part from a URL" looks like
an template copy error
* curl_easy_nextheader: availbleis a typo - available. There are some
minor language issues that can wait for a later review.
curl_easy_header: did you consider returning an array of structures,
rather than just one?
This would look like:
Instead of 'index', provide '*nstrret' (number returned). Or, add a
"VALID" flag to "origin" (clear at [nstrret]), and eliminate the number
returned (index) argument. The application can increment the pointer or
use a loop index (i < nstrret) or ( hout[i].origin & VALID) to walk the
list. If you use the flag, perhaps rename 'origin' to 'flags'.
This eliminates the BADINDEX error and amount/index in the structure(s),
and allows the application to make just one call instead of
one/instance. This seems simpler and more efficient for the
application. Since the library is holding all the headers, it should
not increase the amount of memory required.
The only obvious potential drawback would be if the size of curl_header
struct changes; you might consider adding a 'reserved' element to
future-proof it.
FWIW.
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-22
Date: Tue, 22 Mar 2022 06:47:09 -0400
On 22-Mar-22 04:01, Daniel Stenberg via curl-library wrote:
> On Tue, 15 Mar 2022, Daniel Stenberg via curl-library wrote:
>
>> - https://github.com/curl/curl/pull/8593
>
> I merged the headers API as experimental.
>
> On the blog:
> https://daniel.haxx.se/blog/2022/03/22/a-headers-api-for-libcurl/
>
Some observations from reading the man pages:
* Both man pages : the header "extract a part from a URL" looks like
an template copy error
* curl_easy_nextheader: availbleis a typo - available. There are some
minor language issues that can wait for a later review.
curl_easy_header: did you consider returning an array of structures,
rather than just one?
This would look like:
Instead of 'index', provide '*nstrret' (number returned). Or, add a
"VALID" flag to "origin" (clear at [nstrret]), and eliminate the number
returned (index) argument. The application can increment the pointer or
use a loop index (i < nstrret) or ( hout[i].origin & VALID) to walk the
list. If you use the flag, perhaps rename 'origin' to 'flags'.
This eliminates the BADINDEX error and amount/index in the structure(s),
and allows the application to make just one call instead of
one/instance. This seems simpler and more efficient for the
application. Since the library is holding all the headers, it should
not increase the amount of memory required.
The only obvious potential drawback would be if the size of curl_header
struct changes; you might consider adding a 'reserved' element to
future-proof it.
FWIW.
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-library Etiquette: https://curl.haxx.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature