Why `plain-http` for `http-transport`?

[jonathanjouty]

https://github.com/actions/setup-haskell/blob/c80f11a26659be2b2bcd02f50fdf84ae5a1c7921/src/setup-haskell.ts#L37

We sometimes use a private Hackage server, and we have it configured on HTTPS. This results in an error when running a test workflow (replaced actual URL with <private-hackage-url>):

Run actions/setup-haskell@v1
[...]
Setting up cabal
  /opt/cabal/3.2/bin/cabal user-config update
  Renaming /home/runner/.cabal/config to /home/runner/.cabal/config.backup.
  Writing merged config to /home/runner/.cabal/config.
  /opt/cabal/3.2/bin/cabal update
  Downloading the latest package lists from:
  - hackage.haskell.org
  - <private-hackage-url>
  cabal: The remote repository '<private-hackage-url>' specifies a URL that
  requires HTTPS however the built-in HTTP implementation does not support
  HTTPS. The transport implementations with HTTPS support are curl, wget,
  powershell. One of these will be selected automatically if the corresponding
  external program is available, or one can be selected specifically with the
  global flag --http-transport=

This is a general question though, is it not better to use HTTPS? Is there a reason for using plain-http? I didn't find anything specific looking through git blame...

[hazelweakly]

Ah, interesting. xkcd strikes again :)

The reason for plain-http is that it doesn't rely on the existence of curl or other external binaries on the system PATH and, historically, has been more stable on Windows from what I've seen. Admittedly, it could be seen as a bit of a cargo cult to apply it by default, but it was a recommended method at the time that I started writing this and so I carried it forward from the original implementation.

In the meantime, it should be possible to work around this by running cabal user-config update -a 'http-transport: <transport>' to update the config file (assuming you're using a cabal version greater than 2.0), or with cabal --http-transport=<transport> update. where transport can be one of curl, wget, powershell, or plain-http. I suspect curl is the one you want as that's the default value.

That all being said, immediate fixes out of the way, I can't find any persistent issues remaining with the default option on Windows being reported elsewhere, so I'm thinking that it might be best to not set plain-http by default.

Out of curiosity, I'd be interested in knowing if the workarounds work for you. I don't think I have access to any infrastructure on here that I could use to test an https hackage server, unfortunately.

As for https, hackage.haskell.org itself uses http in the repository stanza of the ~/.cabal/config and I wasn't aware that cabal actually supported https in that field. If it's working for you, I can't see any reason why you should change it, but I am mildly surprised this is the first thing that's broken for you with an https-only private Hackage server (if i'm understanding your setup right)

[jonathanjouty]

Fascinating! Thanks for the explanation :)

This is indeed not the first thing that broke. We also have source-repository-package linking to (some of them private) git repositories, and that too broke due to the action workflow not having permissions for those repositories, i.e. a separate problem to be fixed. The private Hackage could solve that in part, but also solves not having to rebuild the source-repository-package which triggers a re-build of dependencies much more often (I'm sure there's a cabal issue somewhere).

I will try your suggested workaround when I get back to this, thanks.