On Mon, Sep 25, 2023 at 01:52:34PM +0200, Johannes Schindelin wrote: > > You might want "--fail" or "--fail-with-body" here. I think any > > server-side errors (like a missing or invalid token or project name) > > will result in a 401. > > Sadly, https://curl.se/docs/manpage.html#-f says this: > > This method is not fail-safe and there are occasions where > non-successful response codes slip through, especially when > authentication is involved (response codes 401 and 407). > > 401 is the precise case we're hitting when the token or the project name > are incorrect. > > Having said that, I just tested with this particular host, and `curl -f` > does fail with [exit code 22](https://curl.se/docs/manpage.html#22) as one > would desire. So I will make that change. The manpage is rather vague about what those "occasions" are, but I think we are probably OK since we are not sending HTTP-level credentials, according to: https://github.com/curl/curl/commit/cde5e35d9b046b224c64936c432d67c9de8bcc9e At any rate, even if this did not catch every failure, I think we are better off catching more rather than fewer. > As to `--fail-with-body`: it is too new to use (it was [introduced in cURL > v7.76.0](https://curl.se/docs/manpage.html#--fail-with-body) and Ubuntu > v20.04 [comes with > v7.68.0](https://packages.ubuntu.com/search?suite=focal&searchon=names&keywords=curl), > i.e. is missing that option). > > In any case, in my tests, `--fail-with-body` did not show anything more > than `--fail` in this instance. Maybe for you it is different? No, I don't think it's worth worrying about here. It could help with debugging if their server returns something generic like a 500 code along with a more detailed reason (we do something similar in git-remote-curl to show failed bodies). But if it's at all more hassle than typing "--with-body" it is not worth the effort. > > I notice you put the "project" variable in the query string. Can it be > > a --form, too, for symmetry? > > The instructions at https://scan.coverity.com/projects/git/builds/new (in > the "Automation" section) are very clear that `project` should be passed > as a GET variable. > > Even if using a POST variable would work, I'd rather stay with the > officially-documented way. That seems like good reasoning to me. -Peff
