- generate AVAILABILITY manpage sections automatically - for consistent
wording
- allows us to double-check against other documumentation (symbols-in-versions
etc)
- enables proper automation/scripting based on this data
- lots of them were wrong or missing in the manpages
- several of them repeated (sometimes mismatching) backend support info
Add test 1488 to verify "added-in" version numbers against
symbols-in-versions.
Closes#14217
- Parse etag and content-disposition headers for 3xx replies.
For example, a server may send a content-disposition filename header
with a redirect reply (3xx) but not with the final response (2xx).
Without this change curl would ignore the server's specified filename
and continue to use the filename extracted from the user-specified URL.
Prior to this change, 75d79a4 had limited etag and content-disposition
to 2xx replies only.
Tests-by: Daniel Stenberg
Reported-by: Morgan Willcock
Fixes https://github.com/curl/curl/issues/13302Closes#13484
Introduce new notation for CURLOPT_INTERFACE / --interface:
ifhost!<interface>!<host>
Binding to an interface doesn't set the address, and an interface can
have multiple addresses.
When binding to an address (without interface), the kernel is free to
choose the route, and it can route through any device that can access
the target address, not necessarily the one with the chosen address.
Moreover, it is possible for different interfaces to have the same IP
address, on which case we need to provide a way to be more specific.
Factor out the parsing part of interface option, and add unit tests:
1663.
Closes#13719
Refactors canon_query, so it could use the encoding part of the function
to use it in the path.
As the path doesn't encode '/', but encode '=', I had to add some
conditions to know If I was doing the query or path encoding.
Also, instead of adding a `bool in_path` variable, I use `bool
*found_equals` to know if the function was called for the query or path,
as found_equals is used only in query_encoding.
Test 472 verifies.
Reported-by: Alexander Shtuchkin
Fixes#13754Closes#13814
Signed-off-by: Matthias Gatto <matthias.gatto@outscale.com>
- HEADERFUNCTIONS might inspect response properties like
CURLINFO_CONTENT_LENGTH_DOWNLOAD_T on seeing the last header line. If
the line is being written before this is initialized, values are not
available.
- write the last header line late when analyzing a HTTP response so that
all information is available at the time of the writing.
- add test1485 to verify that CURLINFO_CONTENT_LENGTH_DOWNLOAD_T works
on seeing the last header.
Fixes#13752
Reported-by: Harry Sintonen
Closes#13757
with more than one transfer-encoding, 'chunked' must be the last added
to the writer stack (and therefore the first to decode). RFC 9112, ch.
6.1.
Closes#13736
Verifies that the issue in #13669 actually is fixed. This return code is
what the CURLOPT_WRITEFUNCTION manpage documents should be returned.
This code is mostly from the
Source-written-by: Trumeet on github
Closes#13671
- ignore duplicate "chunked" transfer-encodings from
a server to accomodate for broken implementations
- add test1482 and test1483
Reported-by: Mel Zuser
Fixes#13451Closes#13461
Use a lookup list to set the cipher suites, allowing the
ciphers to be set by either openssl or IANA names.
To keep the binary size of the lookup list down we compress
each entry in the cipher list down to 2 + 6 bytes using the
C preprocessor.
Closes#13442
This fixes a regression of 75d79a4486. The
code in tool-operate truncated the etag save file, under the assumption
that the file would be written with a new etag value. However since
75d79a4486 that might not be the case
anymore and could result in the file being truncated when --etag-compare
and --etag-save was used and that the etag value matched with what the
server responded. Instead the truncation should not be done when a new
etag value should be written.
Test 3204 was added to verify that the file with the etag value doesn't
change the contents when used by --etag-compare and --etage-save and
that value matches with what the server returns on a non 2xx response.
Closes#13432
A connection that has seen an HTTP major version now refuses any other
major HTTP version in future responses. Previously, a HTTP/1.x
connection would just silently accept HTTP/2 or HTTP/3 in the status
lines as long as it had support for those built-in. It would then just
lead to confusion and badness.
Indirectly Spotted by CodeSonar which identified a duplicate assignment
in this function.
Add test 471 to verify
Closes#13421
- add `Curl_hash_offt` as hashmap between a `curl_off_t` and
an object. Use this in h2+h3 connection filters to associate
`data->id` with the internal stream state.
- changed implementations of all affected connection filters
- removed `h2_ctx*` and `h3_ctx*` from `struct HTTP` and thus
the easy handle
- solves the problem of attaching "foreign protocol" easy handles
during connection shutdown
Test 1616 verifies the new hash functions.
Closes#13204
The option is really two enums ORed together, so it needs special
attention to make the code output nice.
Added test 1481 to verify. Both the server and the proxy versions.
Reported-by: Boris Verkhovskiy
Fixes#13127Closes#13129
... correctly, even when they follow an existing one without a space in
between.
Verify with test 467
Follow-up to 07dd60c05b
Reported-by: Geeknik Labs
Fixes#13101Closes#13102
If a response without a status line is received, and the connection is
known to use HTTP/1.x (not HTTP/0.9), report the error "Invalid status
line" instead of "Received HTTP/0.9 when not allowed".
Closes#13045
When disabling all protocols without enabling any, the resulting
set of allowed protocols remained the default set. Clearing the
allowed set before inspecting the passed value from --proto make
the set empty even in the errorpath of no protocols enabled.
Co-authored-by: Dan Fandrich <dan@telarity.com>
Reported-by: Dan Fandrich <dan@telarity.com>
Reviewed-by: Daniel Stenberg <daniel@haxx.se>
Closes: #13004
Like when trying to import an environment variable that does not exist.
Also fix a bug for reading env variables when there is a default value
set.
Bug: https://curl.se/mail/archive-2024-02/0008.html
Reported-by: Brett Buddin
Add test 462 to verify.
Closes#12862
and mark the stream for close, but return OK since the response this far
was ok - if headers were received. Partly because this is what curl has
done traditionally.
Test 499 verifies. Updates test 689.
Reported-by: Sergey Bronnikov
Bug: https://curl.se/mail/lib-2024-02/0000.htmlCloses#12842
- Use http authentication mechanisms as a default, not a preset.
Consider http authentication options which are mapped to SASL options as
a default (overriding the hardcoded default mask for the protocol) that
is ignored if a login option string is given.
Prior to this change, if some HTTP auth options were given, sasl mapped
http authentication options to sasl ones but merged them with the login
options.
That caused problems with the cli tool that sets the http login option
CURLAUTH_BEARER as a side-effect of --oauth2-bearer, because this flag
maps to more than one sasl mechanisms and the latter cannot be cleared
individually by the login options string.
New test 992 checks this.
Fixes https://github.com/curl/curl/issues/10259
Closes https://github.com/curl/curl/pull/12790
When checking if the user wants to replace the header, the check should
be case insensitive.
Adding test 461 to verify
Found-by: Dan Fandrich
Ref: #12782Closes#12784
- in en- and decoding, check the websocket frame payload lengths for
negative values (from curl_off_t) and error the operation in that case
- add test 2307 to verify
Closes#12707
- enforce a response body length of 0, if the
response has no Content-lenght. This is according
to the RTSP spec.
- excess bytes in a response body are forwarded to
the client writers which will report and fail the
transfer
Follow-up to d7b6ce6Fixes#12701Closes#12706
char variables if unspecified can be either signed or unsigned depending
on the platform according to the C standard; in most platforms, they are
signed.
This meant that the *i<32 waas always true for bytes with the top bit
set. So they were always getting encoded as \uXXXX, and then since they
were also signed negative, they were getting extended with 1s causing
'\xe2' to be expanded to \uffffffe2, for example:
$ curl --variable 'v=“' --expand-write-out '{{v:json}}\n' file:///dev/null
\uffffffe2\uffffff80\uffffff9c
I fixed this bug by making the code use explicitly unsigned char*
variables instead of char* variables.
Test 268 verifies
Reported-by: iconoclasthero
Closes#12434
The script errorcodes.pl extracts all error codes from all headers and
checks that they are all documented, then checks that all documented
error codes are also specified in a header file.
Closes#12424
When the config file parser detects a word that *probably* should be
quoted, mention double-quotes as a possible remedy.
Test 459 verifies.
Proposed-by: Jiehong on github
Fixes#12409Closes#12412
