I'm sure this solves someone's problem, but reading https://everything.curl.dev/cmdline/variables.html makes me wonder whether curl really needs this added complexity
And, if you don’t need them, don’t use them! Have you seen how many options curl has? But never good ones to support range requests until now.
As shown here:
$ python3 -m http.server 9090 &
# that doesn't matter, just return _something_ on :9090
$ ls -l .DS_Store
-rw-r--r--@ 1 mdaniel staff 18436 Dec 30 11:30 .DS_Store
$ curl -vo .DS_Store -C - http://127.0.0.1:9090/.DS_Store
** Resuming transfer from byte position 18436
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 127.0.0.1:9090...
* Connected to 127.0.0.1 (127.0.0.1) port 9090
> GET /.DS_Store HTTP/1.1
> Host: 127.0.0.1:9090
> Range: bytes=18436-
> User-Agent: curl/8.7.1
> Accept: */*
One can see where curl helpfully loaded the local file's 18436 size, set up the Range header, and included it on the first-contact with the http server.While digging into this, there's actually one for its modification time, too. Curl knows all:
$ curl -v --time-cond .DS_Store -o .DS_Store -C - http://127.0.0.1:9090/.DS_Store
> If-Modified-Since: Mon, 30 Dec 2024 19:30:50 GMT
As for your "well, just don't use it then" stance, it has been my experience in building software that the Law of Unintended Consequences is brutal. The first bug report filed where someone discovers that a `--header` argument cannot contain {{ anymore due to a fat-fingered function change will let me put another quarter in the I Told You So jarThis seems much more readable than the stuff introduced here, and I would still heavily prefer to do it this way.