Before `#parse_curl_output` was introduced and related methods were
updated to use it, `#url_protected_by_cloudflare?` and
`#url_protected_by_incapsula?` were checking a string of all the
headers from a response and using a regex to check related header
values.
However, when `#curl_http_content_headers_and_checksum` was updated
to use `#parse_curl_output` internally, the `:headers` value became
a hash generated by `#parse_curl_response`. The `#url_protected_by_*`
methods were updated to work with the hash value but this wasn't able
to fully replicate the previous behavior because
`#parse_curl_response` was only keeping the last instance of a given
header (maintaining pre-existing behavior). This is an issue for
these methods because they check `Set-Cookie` headers and there can
be multiple instances of this header in a response.
This commit updates these methods to handle an array of strings in
addition to the existing string support. This change ensures that
these methods properly check all `Set-Cookie` headers, effectively
reinstating the previous behavior.
Past that, this updates one of the early return values in
`#url_protected_by_cloudflare?` to be `false` instead of an implicit
`nil`. After adding a type signature to this method, it became clear
that it wasn't always returning a boolean value and this fixes it.
`Curl#parse_curl_response` only includes the last instance of a given
header in its `:headers` hash (replicating pre-existing behavior).
This is a problem for headers like `Set-Cookie`, which can appear more
than once in a response.
This commit addresses the issue by collecting duplicate headers into
an array instead. Headers that only appear once in the response will
still have a string value but headers that appear more than once will
be an array of strings. Whenever headers from `#parse_curl_response`
are used (directly or indirectly), it's important to conditionally
handle the expected types.
The problem occurred when calling `brew reinstall` on a cask
with an out of date caskfile.
To solve the problem Cask::Installer#uninstall_existing_cask has been changed to
catch a possible CaskInvalidError when trying to load outdated
caskfiles using Cask::CaskLoader#load.
Follow up adter #13124
I made the choice to convert the pr variable to an integer
at the very end and adjust the tests.
It would be maybe more consistent to work with an integer
everywhere, but this needs a more careful analysis and we
are in a hurry to fix the homberew-core upload CI
Fixes:
2022-04-11T20:19:34.1395885Z [31mError:[0m : Variable $pr of type Int! was provided invalid value
2022-04-11T20:19:34.1398279Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/utils/github/api.rb:261:in `open_graphql'
2022-04-11T20:19:34.1399774Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/utils/github.rb:310:in `get_workflow_run'
2022-04-11T20:19:34.1403699Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/dev-cmd/pr-pull.rb:418:in `block (4 levels) in pr_pull'
2022-04-11T20:19:34.1405233Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/dev-cmd/pr-pull.rb:417:in `each'
2022-04-11T20:19:34.1406723Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/dev-cmd/pr-pull.rb:417:in `block (3 levels) in pr_pull'
2022-04-11T20:19:34.1408112Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8/lib/ruby/2.6.0/fileutils.rb:128:in `chdir'
2022-04-11T20:19:34.1408986Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8/lib/ruby/2.6.0/fileutils.rb:128:in `cd'
2022-04-11T20:19:34.1409813Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/dev-cmd/pr-pull.rb:400:in `block (2 levels) in pr_pull'
2022-04-11T20:19:34.1410671Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.8/lib/ruby/2.6.0/tmpdir.rb:93:in `mktmpdir'
2022-04-11T20:19:34.1411495Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/dev-cmd/pr-pull.rb:399:in `block in pr_pull'
2022-04-11T20:19:34.1412250Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/dev-cmd/pr-pull.rb:388:in `each'
2022-04-11T20:19:34.1413056Z /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/dev-cmd/pr-pull.rb:388:in `pr_pull'
- The `brew uninstall` command has `--zap`, so let's make `brew
reinstall` have parity here for a better user experience. (Requested
in issue 12983.)
- It feels weird that to get my new reinstall test to pass I had to add
`--zap` to `cask/cmd/install.rb`, not `cask/cmd/reinstall.rb` to get
the tests to pass. But the `brew reinstall --cask caffeine --zap`
command worked fine all the time. The CLI argument parser from the
test run was complaining about not knowing what `zap` was. As a
result, `--zap` now shows up as a switch in `brew install --help`
which I'm not 100% convinced is the desired UX. But I've edited the
description accordingly to specify that it will only work on
`reinstall` operations (and `--zap` on `install` is a no-op).
```
issyl0 at pictor in /opt/homebrew on reinstall-cask-zap
❯ brew reinstall --cask caffeine --zap
==> Downloading https://github.com/IntelliScape/caffeine/releases/download/1.1.3/Caffeine.dmg
Already downloaded: /Users/issyl0/Library/Caches/Homebrew/downloads/3d6ccfdd3b8d0ab37d1c2468d6e69078c2d31d3b12bf51947c4db21e5f376af2--Caffeine.dmg
==> Implied `brew uninstall --cask caffeine`
==> Backing App 'Caffeine.app' up to '/opt/homebrew/Caskroom/caffeine/1.1.3/Caffeine.app'
==> Removing App '/Applications/Caffeine.app'
==> Dispatching zap stanza
==> Trashing files:
~/Library/Application Support/com.intelliscapesolutions.caffeine
~/Library/Preferences/com.intelliscapesolutions.caffeine.plist
~/Library/Caches/com.intelliscapesolutions.caffeine
~/Library/HTTPStoages/com.intelliscapesolutions.caffeine.binarycookies
==> Removing all staged versions of Cask 'caffeine'
==> Installing Cask caffeine
==> Moving App 'Caffeine.app' to '/Applications/Caffeine.app'
🍺 caffeine was successfully installed!
```
