curl / Mailing Lists / curl-users / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: [man-pages] Discrepancy between --fail-with-body and --fail

From: Vincent MAILHOL via curl-users <curl-users_at_lists.haxx.se>
Date: Wed, 24 Apr 2024 11:05:00 +0900

On Wed. 24 Apr. 2024 at 05:49, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Wed, 24 Apr 2024, Vincent MAILHOL via curl-users wrote:
>
> > 1. --fail-with-body returns an error if the http response code is
> > 400 or greater
> >
> > 2. --fail-with-body and --fail would fail under the same circumstances
> >
> > 3. for --fail, error code between 401 and 407 would "slip through"
> >
> > Those three conditions result in a logical contradiction. At least one of
> > those should be incorrect. To the extent of my knowledge, the third one
> > seems incorrect, but not fully sure of that.
>
> I think (2) is incorrect. The 401 and 407 exceptions mentioned for --fail does
> not seem to exist for --fail-with-body.

Hmmm, I am not familiar with curl code base, so I just did an empirical test.

Consider this script:

  for http_error in 200 {401..407}; do
        url="https://httpbin.org/status/${http_error}";
        curl --silent --fail ${url} > /dev/null;
        echo "curl returns $? for ${url}";
  done

Here is the output:

  curl returns 0 for https://httpbin.org/status/200
  curl returns 22 for https://httpbin.org/status/401
  curl returns 22 for https://httpbin.org/status/402
  curl returns 22 for https://httpbin.org/status/403
  curl returns 22 for https://httpbin.org/status/404
  curl returns 22 for https://httpbin.org/status/405
  curl returns 22 for https://httpbin.org/status/406
  curl returns 22 for https://httpbin.org/status/407

When replacing --fail by --fail-with-body in the script, the results
remain the same. Thus, me saying in my previous message that --fail
and --fail-with-body looks indeed similar and (3) is incorrect.

Does that make sense, or am I missing something else?


FYI, and in case this matters, here is my curl version

  $ curl --version
  curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.1.5
  zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2
  (+libidn2/2.3.4) libssh2/1.11.0 nghttp2/1.59.0 librtmp/2.3
  OpenLDAP/2.5.13 Release-Date: 2023-12-06, security patched: 8.5.0-2
  Protocols: dict file ftp ftps gopher gophers http https imap imaps
  ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps
  telnet tftp
  Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy
  IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe
  TLS-SRP UnixSockets zstd


Yours sincerely,
Vincent Mailhol
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette:   https://curl.se/mail/etiquette.html
Received on 2024-04-24