ChronoSync Cask

[tc-2026]

Output of brew config

.

Output of brew doctor

.

Description of issue

Why does the ChronoSync Cask download the file multiple times? It looks like it performs a 'HEAD', 'GET', 'GET', 'HEAD', 'GET' when fetching the update.

Relevant casks

ChronoSync Cask

[p-linnane]

The output of brew config and brew doctor is not optional.

I am not able to reproduce this.

[tc-2026]

I don't have access to that information. What I do have is access to the apache logs. We're seeing the following:

146.135.6.4 - - [16/May/2026:21:47:01 -0400] "HEAD /CS4_Download.dmg HTTP/2.0" 200 102704600 "-" "Homebrew/5.1.11 (Macintosh; arm64 Mac OS X 15.7.4) curl/8.7.1"
146.135.6.4 - - [16/May/2026:21:47:02 -0400] "GET /CS4_Download.dmg HTTP/1.1" 200 102704600 "-" "Homebrew/5.1.11 (Macintosh; arm64 Mac OS X 15.7.4) curl/8.7.1"
146.135.6.4 - - [16/May/2026:21:47:02 -0400] "GET /CS4_Download.dmg HTTP/2.0" 200 102704600 "-" "Homebrew/5.1.11 (Macintosh; arm64 Mac OS X 15.7.4) curl/8.7.1"
146.135.6.4 - - [16/May/2026:21:47:51 -0400] "HEAD /CS4_Download.dmg HTTP/2.0" 200 102704600 "-" "Homebrew/5.1.11 (Macintosh; arm64 Mac OS X 15.7.4) curl/8.7.1"
146.135.6.4 - - [16/May/2026:21:47:51 -0400] "GET /CS4_Download.dmg HTTP/1.1" 200 102704600 "-" "Homebrew/5.1.11 (Macintosh; arm64 Mac OS X 15.7.4) curl/8.7.1"

Multiple requests from Homebrew, same IP address and seconds apart. This pattern repeats throughout our access logs.

[tc-2026]

Thank you for looking into this. We don't care about the "HEAD"s. That's negligible.

I'm not sure I understand the behavior, please help me.

The log clearly shows HTTP/1.1 attempted first. The server returns Success with the Data.

The second attempt is HTTP/2.0. Again, the server returns Success with the Data.

Then a second request is received and successfully replied to 49 seconds later.

I'll collect the logs tomorrow, but I have yet to see a single Homebrew user agent NOT follow this pattern. Every Homebrew user agent is requesting the same 100MB data 3 times. So you are trying to tell me that everyone fails HTTP/2.0, falls back to HTTP/1.1, then has an interrupted connection and attempts HTTP/1.1 download a 3rd time in order to succeed? Please elaborate.

(I'm not even digging into the HB user agent that downloaded ChronoSync from Gernmany over 11,000 times the other day. That guy must have something broken and if not resolved, his ISP will get an abuse report.)

Our ChronoSync in-app update only makes one request. Gets the data and updates the App.

Since this is our bandwidth we're paying for, we will prioritize ChronoSync in-app update if we cannot find a resolution.

If you believe there is a bug in curl, I'll be happy to help. The developer has always been responsive when I've reported problems.

[bevanjkay]

Ok, sorry I did have the order backwards for the requests.

What is meant to happen, we send a HEAD request and if there is no Content-Disposition header and the required information cannot be detected, we then do a GET request with --head passed to curl so the connection is closed as soon as headers are returned, this does not result in the 100mb file actually being downloaded, but the value is returned in the header. The final request is the HTTP/2.0 GET request that actually downloads the file.

If a content-disposition header is added for the HEAD request then the subsequent GET request shouldn't be required.
curl -sI --location "https://downloads.econtechnologies.com/CS4_Download.dmg"

If the download succeeds it will only be fully downloaded once per invocation, the other requests may fetch headers.

One of the other Homebrew maintainers may have a better understanding of these mechanisms, but this is my understanding.

[daeho-ro]

Here is my apache local test log

172.18.0.1 - - [20/May/2026:21:54:01 +0900] "HEAD /CS4_Download.dmg HTTP/2.0" 200 102705152 sent=146 range_req="-" range_resp="-" content_length="102705152" time=1423us proto=HTTP/2.0 ua="Homebrew/5.1.12-23-g06ccb51 (Macintosh; arm64 Mac OS X 26.4.1) curl/8.7.1"
172.18.0.1 - - [20/May/2026:21:54:01 +0900] "GET /CS4_Download.dmg HTTP/1.1" 200 102705152 sent=419667 range_req="-" range_resp="-" content_length="102705152" time=2809us proto=HTTP/1.1 ua="Homebrew/5.1.12-23-g06ccb51 (Macintosh; arm64 Mac OS X 26.4.1) curl/8.7.1"
172.18.0.1 - - [20/May/2026:21:54:01 +0900] "GET /CS4_Download.dmg HTTP/2.0" 200 102705152 sent=102761800 range_req="-" range_resp="-" content_length="102705152" time=588934us proto=HTTP/2.0 ua="Homebrew/5.1.12-23-g06ccb51 (Macintosh; arm64 Mac OS X 26.4.1) curl/8.7.1"
172.18.0.1 - - [20/May/2026:21:54:02 +0900] "HEAD /CS4_Download.dmg HTTP/2.0" 200 102705152 sent=146 range_req="-" range_resp="-" content_length="102705152" time=493us proto=HTTP/2.0 ua="Homebrew/5.1.12-23-g06ccb51 (Macintosh; arm64 Mac OS X 26.4.1) curl/8.7.1"
172.18.0.1 - - [20/May/2026:21:54:02 +0900] "GET /CS4_Download.dmg HTTP/1.1" 200 102705152 sent=3155169 range_req="-" range_resp="-" content_length="102705152" time=4733us proto=HTTP/1.1 ua="Homebrew/5.1.12-23-g06ccb51 (Macintosh; arm64 Mac OS X 26.4.1) curl/8.7.1"

You can see the actual bytes sent is not ~300MB. Here is the summary for each request,

[1] HEAD HTTP/2.0  sent=146      — Metadata probe (Content-Length, Last-Modified, Content-Disposition) for the download-queue worker via curl_headers; the first --head attempt.
[2] GET  HTTP/1.1  sent=420KB    — Fallback HEAD-as-GET retried because the first HEAD did not return Content-Disposition; same curl_headers call, second loop iteration, forced to HTTP/1.1 by the issue #18213 workaround.
[3] GET  HTTP/2.0  sent=100MB    — The actual file download by the worker (curl_download → curl with --output), HTTP/2 ALPN, only request that transfers the full body.
[4] HEAD HTTP/2.0  sent=146      — Second metadata probe from the main thread's install/stage path; because sha256 :no_check leaves no checksum to verify cache freshness, CurlDownloadStrategy#fetch re-runs resolve_url_basename_time_file_size to compare Last-Modified / Content-Length against the cached file.
[5] GET  HTTP/1.1  sent=1.6MB    — Same fallback HEAD-as-GET retry as [2], triggered by the second curl_headers call in [4]; no real download follows because cached_location_valid is now true.

[tc-2026]

Thank you for the thorough explanation of the process.

We don't have the detailed logging enabled, so didn't see the difference in responses.

Now that I understand the process, I've injected the 'Content-Disposition' header on all .dmg requests. Further, I've published hashes for CS_Download.dmg and CA_Mac_Download.dmg in the same folder.