Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tooling to check for HTTPS versions of cask URLs #5804

Closed
federicobond opened this issue Aug 17, 2014 · 6 comments
Closed

Add tooling to check for HTTPS versions of cask URLs #5804

federicobond opened this issue Aug 17, 2014 · 6 comments

Comments

@federicobond
Copy link
Contributor

I saw some cask updates losing their https links and I though we could add a tool to migrate all those casks that have an HTTPS version of the download link (and maybe homepage too) available but are not currently using it.

@rolandwalker
Copy link
Contributor

Yes, I mass converted some HTTP URLs to HTTPS at one point but didn't save the scripts I used to do so.

However, there was a flaw in my method, which is that I didn't detect when HTTPS gets redirected to HTTP. For those cases, it would be better to revert to HTTP.

@federicobond
Copy link
Contributor Author

I spent a couple of minutes trying to work around the Cask::LinkChecker code. My initial idea was to implement some sort of brew cask checklinks --try-https that would raise a warning for Casks that have an HTTPs endpoint available but are not currently using it.

Unfortunately, the code in Cask::LinkChecker is too stateful to make that work as it is. So, I have two options: either remove the state from it (make it return a Cask::LinkChecker::Response object) or implement the checker outside of the core using brew cask _stanza url. What do you think?

@rolandwalker
Copy link
Contributor

Your call: there are merits either way.

brew cask _stanza is theoretically unstable, but in practice I can't imagine why it would change.

@federicobond
Copy link
Contributor Author

Status update: removing state from Cask::LinkChecker was too much work for relatively little gain so I created a small shell script to query the url stanza and look for a 2xx or 3xx return value using curl. There were some false positives but overall I managed to update almost 100 casks.

Should I submit a single PR with all these changes?

@rolandwalker
Copy link
Contributor

A single PR is fine, though it is better if the PR contains one-commit-per Cask.

After a mass change, I usually try to keep a lookout for any user submissions that caught a merge conflict and fix that for the user manually.

(Odd that there were still so many – I must have forgotten something in #4967 or #4968.)

@vitorgalvao
Copy link
Member

Closing for lack of implementation. This is can be revisited later.

@Homebrew Homebrew locked and limited conversation to collaborators May 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants