Allow for custom headers during livecheck request

[gtmn]

Provide a detailed description of the proposed feature

Allow to send custom headers for livecheck the way it's allowed for url as well.

What is the motivation for the feature?

Ability to execute livechecks for formulas to a homepage which requires a specific header / cookie to be present in order to access the website.

Further, see as well the same feature request which closed automatically though: #11675

How will the feature be relevant to at least 90% of Homebrew users?

Contributors for formulas can support a broader range of livechecks for formulas. Private formulas for example within a company network can easily implement a livecheck for their formula.

What alternatives to the feature have been considered?

None, no simple and reusable alternative available.

[MikeMcQuaid]

CC @samford @nandahkrishna for thoughts here.

[samford]

For additional context, there are also a small number of checks where we need to make a POST request and these two ideas are part of the same overarching feature. In my experience, the number of checks that require this kind of configuration is very small (I've documented fewer than 10 but the real number is probably a little more than that).

This has been planned for some time and is one part of a broader feature that I've been calling options (allowing us to configure parts of curl, strategies, etc.). I've had a tentative implementation finished for quite a while but have been working through some other items on my livecheck to-do list first. There's one PR that I want to create first (i.e., the work's done and I just want to get it out of the way) but then this should be next on the list, as it regularly comes up in discussions and underpins some other features I'm working on. [For what it's worth, I missed the previous issue on this topic but Bevan is already aware of the forthcoming options feature, as we've discussed this in previous homebrew/cask PRs.]

The main reason why I haven't created an options PR yet is that it will require a bit of discussion around the shape of the API (though the internals behind it likely won't change much), so I've been trying to find some time where I have the bandwidth for it (I've been a bit busier than usual outside of Homebrew recently). I've also been trying to wait for our GSoC livecheck project to get past the point where it's modifying livecheck's internals, as I don't want to create conflicts that adds to our student's burden.

The PR I want to get out of the way first modifies unrelated parts of livecheck, so it won't create conflicts for the current GSoC work (but there's a compelling reason to get it done sooner rather than later). I'll try to get that out sometime in the next few days. Once that's finished, I can always create a PR for the options work and label it "Do not merge", so we can discuss it while this GSoC work is ongoing and merge it when it won't create conflicts.

[MikeMcQuaid]

Thanks @samford. Given this do you think this issue is help wanted or close as unplanned for now?

[samford]

"Help wanted" doesn't feel right because I have a finished implementation already and I just need to create a PR. Closing as unplanned also doesn't quite feel right because this has been a planned feature for a long time. If I had to choose between those two options, I suppose that closing this would be more appropriate, though.

However, being able to control curl's behavior in certain ways (like this) is a recurring request, so there's something to be said for leaving this open for the moment and I can just assign myself to it. Alternatively, I could open a PR for the options work, label it "do not merge", link it to this issue, and simply discuss the API as time permits. Are either of these ideas amenable? It's totally fine if they're not but I figured I would float the idea, at least.

[carlocab]

in progress and assigning yourself seems appropriate then?

[MikeMcQuaid]

Alternatively, I could open a PR for the options work, label it "do not merge", link it to this issue, and simply discuss the API as time permits. Are either of these ideas amenable?

This sounds good! Go for draft PR too.

[MikeMcQuaid]

Passing on this. We'll review a PR but not going to leave it open indefinitely, sorry!

[samford]

No worries. I'm roughly a couple of brew PRs away from creating a PR for the underlying changes that enable this (it's done but I just need to work through my PR backlog).