Open apparentorder opened 10 months ago
It is possible there is some build-time configuration define
that we aren't setting when building the bundled libcurl version that usually gets set when libcurl is built using its typical distro build chain. I would check here to see if there is a HAVE_
variable that may be necessary that we aren't setting. Being limited to a 32-bit timestamp sounds an awful lot like libcurl wanting to detect optional 64-bit timestamp support, and our build script not informing libcurl of the timestamp width of the target triple.
I'll also mention https://github.com/alexcrichton/curl-rust/issues/321 here because I was completely unaware that I forgot to install libcurl-devel, and I was really surprised that some libcurl gets bundled silently.
I think we're likely to close that issue as "won't fix". Not only would not falling back to the bundled libcurl be a breaking change, it would also be annoying for most users who would rather see compiling curl-rust to "just work" whether or not a system libcurl is available rather than needing to opt-in to a bundled version somehow. That's been @alexcrichton's general stance too if I recall.
When curl-rust is using the bundled libcurl, it will silently limit the expiry time (unix timestamp) of received cookies to i32::MAX (2147483647), for example:
But "Thu, 13 Jan 2078 22:23:01 GMT" actually is 3409338181.
I have reproduced this on different OS (Amazon Linux, Ubuntu) and different architectures (x86-64, aarch64).
When libcurl header files are present and curl-rust is built without the bundled libcurl, this bug does not occur. Assorted versions of the
curl
client also seem to be unaffected.Test program:
With bundled libcurl, the output will contain the above line, and also:
I'll also mention #321 here because I was completely unaware that I forgot to install libcurl-devel, and I was really surprised that some libcurl gets bundled silently.