- Make content length (ie download size) accessible to the user in the
header callback, but only after all headers have been processed (ie
only in the final call to the header callback).
Background:
For a long time the content length could be retrieved in the header
callback via CURLINFO_CONTENT_LENGTH_DOWNLOAD_T as soon as it was parsed
by curl.
Changes were made in 8a16e54 (precedes 7.79.0) to ignore content length
if any transfer encoding is used. A side effect of that was that
content length was not set by libcurl until after the header callback
was called the final time, because until all headers are processed it
cannot be determined if content length is valid.
This change keeps the same intention --all headers must be processed--
but now the content length is available before the final call to the
header function that indicates all headers have been processed (ie
a blank header).
Bug: https://github.com/curl/curl/commit/8a16e54#r57374914
Reported-by: sergio-nsk@users.noreply.github.com
Co-authored-by: Daniel Stenberg
Fixes https://github.com/curl/curl/issues/7804
Closes https://github.com/curl/curl/pull/7803
Pass on better return codes when errors occur within Curl_http instead
of insisting that CURLE_OUT_OF_MEMORY is the only possible one.
Pointed-out-by: Jay Satiro
Closes#7851
1. it's superfluous
2. it didn't work identically to the Curl_hyper_stream one which could
cause problems like #7486
Pointed-out-by: David Cook
Closes#7499
- the data needs to be "line-based" anyway since it's also passed to the
debug callback/application
- it makes infof() work like failf() and consistency is good
- there's an assert that triggers on newlines in the format string
- Also removes a few instances of "..."
- Removes the code that would append "..." to the end of the data *iff*
it was truncated in infof()
Closes#7357
To prevent previous ones to get reused on subsequent requests. Matches
how the built-in HTTP code works. Makes test 90 to 93 work.
Add test 90 to 93 in travis.
Closes#7139
Some of the time, we get a HYPER_TASK_EMPTY response before the status
line, headers, and body have been read. Previously, that would cause us
to poll again, leading to a 1 second timeout.
The HYPER_TASK_EMPTY docs say:
The value of this task is null (does not imply an error).
So, if we receive a HYPER_TASK_EMPTY, continue on with processing the
response.
Reported-by: Kevin Burke
Fixes#7064Closes#7070
Previously if a caller set CURLOPT_WRITEFUNCTION but did not set a
CURLOPT_HEADERDATA buffer, Hyper would still attempt to write headers to
the data->set.writeheader header buffer, even though it is null. This
led to NPE segfaults attempting to use libcurl+Hyper with Git, for
example.
Instead, process the client write for the status line using the same
logic we use to process the client write for the later HTTP headers,
which contains the appropriate guard logic. As a side benefit,
data->set.writeheader is now only read in one file instead of two.
Fixes#6619Fixesabetterinternet/crustls#49Fixeshyperium/hyper#2438Closes#6971
Both were used for the same purposes and there was no logical separation
between them. Combined, this also saves 16 bytes in less holes in my
test build.
Closes#6798
Rename it to 'httpwant' and make a cloned field in the state struct as
well for run-time updates.
Also: refuse non-supported HTTP versions. Verified with test 129.
Closes#6585
... in most cases instead of 'struct connectdata *' but in some cases in
addition to.
- We mostly operate on transfers and not connections.
- We need the transfer handle to log, store data and more. Everything in
libcurl is driven by a transfer (the CURL * in the public API).
- This work clarifies and separates the transfers from the connections
better.
- We should avoid "conn->data". Since individual connections can be used
by many transfers when multiplexing, making sure that conn->data
points to the current and correct transfer at all times is difficult
and has been notoriously error-prone over the years. The goal is to
ultimately remove the conn->data pointer for this reason.
Closes#6425
When doing a request with a request body expecting a 401/407 back, that
initial request is sent with a zero content-length. Test 177 and more.
Closes#6424