Improve detection of file extensions in CurlDownloadStrategy #3916
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
brew style
with your changes locally?brew tests
with your changes locally?The issue
Sometimes,
brew cask fetch
/install
fails with an error message similar to this:Steps to reproduce (in the lab)
To reproduce the issue, check out this branch and run the
cask/download_strategy
test suite:Steps to reproduce (in the wild)
One real-life example would be a Cask whose URL has 1. no
.
character anywhere in the URL path itself (outside of the domain name), and 2. at least one query parameter with a.
character in it; and 3. other query parameters following that with a combined length of more than 255 characters.This combination may be uncommon but it exists, especially in URLs that change on every visit, for example
steamed-hams
from myclaui/cask-games
tap:Analysis
In a nutshell, URL query strings sometimes look like a very long file extension to Homebrew, which it then proceeds to use as a file name.
In
CurlDownloadStrategy
, Homebrew seems to apply a heuristic to the cask URL in order to figure out a possibly meaningful file extension. Sometimes this heuristic produces immensely long file extensions, especially when there’s a query parameter with a.
character in it but not in the URL path itself (outside of the domain name).Homebrew then believes that everything after the
.
is a file extension. In one of the later steps, it tries to create a lock file containing that extension, which fails because HFS+ cannot handle files whose base file name has more than 255 characters.Fix
This PR improves Homebrew’s extension detector a bit so that it won’t cross individual URL query param boundaries any longer. This is done by adding
&
as a stop character:This appears to fix the issue for most (if not all) practical purposes.