For many years we’ve had this outstanding idea to add a new API to libcurl that would offer applications easy access to HTTP response headers.<\/p>\n\n\n\n
Applications could already retrieve the headers using existing methods but that requires them to write a callback and to a certain amount of parsing and “understanding” HTTP that we always felt was a little unfortunate, a bit error-prone on the behalf of the applications and perhaps also a thing that forced a lot of applications out there having to write the same kind of extra function logic.<\/p>\n\n\n\n
If libcurl provides this functionality, it would remove a lot of (duplicated) code from a lot of applications.<\/p>\n\n\n\n
We started this process a while ago when I first wrote down a basic approach to an API for this and sent it off to the curl-library mailing list<\/a> for feedback and critique.<\/p>\n\n\n\n The conversation that followed that first plea for help, made me realize that my first proposal had been far too basic and it wouldn’t at all work to satisfy the needs and use cases we could think of for this API.<\/p>\n\n\n\n I went back to mull over what I’ve learned and update my design proposal, trying to take the feedback into account in the best possible way. A few weeks later, I returned with a “proposal v2” and again I asked for comments and opinions on what I had put together.<\/p>\n\n\n\n As I had already adjusted the API from feedback the first time around, the feedback this time was perhaps not calling for as big changes or radical differences as they did the first time around. I could adapt my proposal to what people asked and suggested. We arrived at something that seemed like a pretty solid API for offering HTTP headers to applications.<\/p>\n\n\n\n As the API proposal feedback settled down and the interface felt good and sensible, I decided it was time for me to write up a first implementation so that we can offer code to people to give everyone a chance to try out the API in real life as well. There’s one thing to give feedback on a “paper product”, actually being able to use it and try it in an application is way better. I dove in.<\/p>\n\n\n\n When the code worked to the level that I started to be able to extract the first headers with the API, it proved to that we needed to adjust the API a little more, so I did. I then ran into more questions and thoughts about specifics that we hadn’t yet dealt with or nailed proper in the discussions up to that point and I took some questions back to the curl community. This became an iterative process and we smoothed out questions about how access different header “sources” as well as how to deal with multiple headers and “request sequences”. All supported now.<\/p>\n\n\n\n This API allows applications to extract all<\/em> headers from a previous transfer. It can get one or many headers when there are duplicated ones, like The application can ask for “normal” headers, for trailers (that arrive after the body), headers associated with the CONNECT request (if such a one was performed), pseudo headers (that might arrive when HTTP\/2 and HTTP\/3 is used) or headers associated with a HTTP 1xx “intermediate” response.<\/p>\n\n\n\n The libcurl APIs typically work on transfers<\/em>, which means that a single transfer may end up doing multiple transfers, multiple HTTP requests. Primarily when redirects are followed but it can also be due to other reasons. This header API therefore allows the caller to extract headers from the entire “chain” of requests a previous transfer was made with.<\/p>\n\n\n\n This API is initially merged (in this commit<\/a>) labeled “experimental” to be included in the upcoming 7.83.0 release. The experimental<\/em> label means a few different things to us:<\/p>\n\n\n\n We use the experimental “route” to lower the bar for merging new stuff, so that we get some extra chances to fix up mistakes before the rules and API are carved in stone and we are set to support that for a life time.<\/p>\n\n\n\n This setup relies on users actually trying out the experimental stuff as otherwise it isn’t method for improving the API, it will only delay the introduction of it to the general public. And it risks becoming be less good.<\/p>\n\n\n\n The two new functions have detailed man pages: curl_easy_header<\/a> and curl_easy_nextheader<\/a>. If there is anything missing on unclear in there, let us know!<\/p>\n\n\n\n I have also created an initial example source snippet showing header API use. See headerapi.c<\/a>.<\/p>\n\n\n\n This API deserves its own little section in the everything curl<\/a> book, but I think I will wait for it to get landed “for real” before I work on adding that.<\/p>\n","protected":false},"excerpt":{"rendered":" For many years we’ve had this outstanding idea to add a new API to libcurl that would offer applications easy access to HTTP response headers. Applications could already retrieve the headers using existing methods but that requires them to write a callback and to a certain amount of parsing and “understanding” HTTP that we always … Continue reading A headers API for libcurl<\/span> \/* first take *\/\nchar *curl_easy_header(CURL *easy,\n const char *name);<\/pre>\n\n\n\n
Try again<\/h2>\n\n\n\n
\/* second shot *\/\nCURLHcode curl_easy_header(CURL *easy,\n const char *name,\n size_t index,\n struct curl_header **h);\n<\/pre>\n\n\n\n
Let’s do this<\/h2>\n\n\n\n
The final take<\/h2>\n\n\n\n
\/* final version *\/\nCURLHcode curl_easy_header(CURL *easy,\n const char *name,\n size_t index,\n unsigned int origin,\n int request,\n struct curl_header **h);<\/code><\/pre>\n\n\n\nMultiple headers<\/h3>\n\n\n\n
Set-Cookie:<\/code> commonly arrive as.<\/p>\n\n\n\nSources<\/h3>\n\n\n\n
Multiple responses<\/h3>\n\n\n\n
EXPERIMENTAL<\/h2>\n\n\n\n
--enable-headers-api<\/code> when you run configure<\/li>Documentation<\/h2>\n\n\n\n