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: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 22 Mar 2022 17:49:19 +0100 (CET)
On Tue, 22 Mar 2022, Timothe Litt wrote:
> A single API call can guarantee a consistent result. Since you allow this
> to be called while headers are arriving, multiple calls may return different
> counts - presumably only increasing.
That's true. But someone polling header info while headers are still incoming
should hopefully be aware of that not all headers have arrived yet...
> OK. But it's only the structs -- 1 (for the end marker) + #headers vs. 1.
> You're holding the names and values, which hopefully are the large items.
Yes, but also since we would then return a dynamic set of a variable amount of
structs we would have to allocate that memory dynamically. Which we can avoid
now, since we always need the same fixed amount. Simpler.
> One more thought - it might be useful to have a flag bit that indicates when
> the last header has been received.
I had a flag like that in the "spec" for a while and my first implementation
did, but I removed it later when I added support for the whole "chain" of
requests as it then got a little complicated.
There can be "the last header received" several times during a transfer and I
couldn't decide how to signal that proper!
Date: Tue, 22 Mar 2022 17:49:19 +0100 (CET)
On Tue, 22 Mar 2022, Timothe Litt wrote:
> A single API call can guarantee a consistent result. Since you allow this
> to be called while headers are arriving, multiple calls may return different
> counts - presumably only increasing.
That's true. But someone polling header info while headers are still incoming
should hopefully be aware of that not all headers have arrived yet...
> OK. But it's only the structs -- 1 (for the end marker) + #headers vs. 1.
> You're holding the names and values, which hopefully are the large items.
Yes, but also since we would then return a dynamic set of a variable amount of
structs we would have to allocate that memory dynamically. Which we can avoid
now, since we always need the same fixed amount. Simpler.
> One more thought - it might be useful to have a flag bit that indicates when
> the last header has been received.
I had a flag like that in the "spec" for a while and my first implementation
did, but I removed it later when I added support for the whole "chain" of
requests as it then got a little complicated.
There can be "the last header received" several times during a transfer and I
couldn't decide how to signal that proper!
-- / 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-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-03-22