content length not available in header function, again

[piru]

I did this

Use CURLINFO_CONTENT_LENGTH_DOWNLOAD_T in CURLOPT_HEADERFUNCTION function when the last header is processed (empty newline is received). Rather than getting the content length -1 is returned. The call working in this specific scenario is undocumented behaviour that some (broken) code relies on. This issue was tracked earlier as #7804 and has surfaced again couple of versions ago (not sure when exactly).

I expected the following

Maybe this behaviour should be maintained since for example WebKit curl backend (*) is broken now. However, this is undocumented behaviour after all, so not fixing it is perfectly fine as well. WebKit and other code depending on this should be fixed either way.

*) https://github.com/WebKit/WebKit/blob/57affb62969db66ef07975567f4876d62d86da55/Source/WebCore/platform/network/curl/CurlRequest.cpp#L320

curl/libcurl version

curl 8.8.0

operating system

Linux hostname 6.8.9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.8.9-1 (2024-05-15) x86_64 GNU/Linux

[icing]

it's http.c:3630 and following where the \r\n is written to the client before the analysis and the info things are set.
To get what you want, the "Curl_client_write()" needs to be done after "http_on_response()" is called.

[piru]

Ok that works at least in initial tests. I also had to defer Curl_dyn_reset(&data->state.headerb); to occur only after the Curl_client_write() call.

[piru]

Just moving the Curl_dyn_reset later is wrong though, at least when considering the comment at

curl/lib/http.c

Line 3663 in 1c4813c

/* Caveat: we clear anything in the header brigade, because a

I tried creating a dynbuf copy of the hd, hdlen data and then doing Curl_dyn_reset as before, and using the copy for the Curl_client_write. It works (tests pass), but if there is recursion the order of header callbacks changes. I don't feel confident if this would be correct.

[icing]

My proposal on how to solve this - test case included: #13757.