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
