The cask scrapes an HTML page for the latest nightly. Either is
normally served over a secure connection; the URL of the page is:
https://nightlies.videolan.org/build/macosx-intel/last/
However, things happen whenever a user agent requests the same thing
without the trailing `/`:
https://nightlies.videolan.org/build/macosx-intel/last
This apparently fires some quirky server-side rewrite, causing the
server to first _downgrade_ the request via a [HTTP
301](https://http.cat/301) response, adding the trailing slash while
at it, then following up to the second request with an [HTTP
307](https://http.cat/307), immediately _upgrading_ again to HTTPS.
This feels like a server-side misconfiguration to me; it kinda
defeats the purpose of HTTPS and is obviously not wanted by anyone. I
feel the best place to fix this is on the server; I have just
informed j-b (one of the upstream sysadmins) and got a reply that
they’re going to fix it server-side.
That said, I still believe it’s a good idea for the cask to use the
canonical URL anyway – if only to avoid the redirect altogether, and
to be less dependent on a fix. Hence, this commit.
Error: It seems the App source is not there: '/usr/local/Caskroom/vlc-nightly/latest/vlc-3.0.0-git/VLC.app'
- Added correct container type `dmg`
- Added target to allow installation alongside current VLC.app, sharing prefs.
- Added two caveats(!)
Remove caveats and target
commitay
Claudia
Haralan Dobrev
Vítor Galvão
Markus Reiter
Mark Griffiths
Michael Ford
Josh Hagins
Michael
Roland Walker
Allan Odgaard