I did this

See #9508, the first part of which I quote here for convenience:

I have proxy that returns a 503 with application/json content:

$ curl -o - -I -x 'http://x:y@localhost:1234' https://ipinfo.io/ip
HTTP/1.1 503 Service Unavailable
Content-Type: application/problem+json
Date: Thu, 15 Sep 2022 00:22:02 GMT
Content-Length: 214

However, curl does not show the content returned with the error. Is that a bug or some aspect of the HTTP spec that states such content should be ignored?

$ tcpdump -Ai lo port 1234
...
HTTP/1.1 503 Service Unavailable
Content-Type: application/problem+json
Date: Thu, 15 Sep 2022 00:22:02 GMT
Content-Length: 214

{"type":"https://xxx.com/problems/xxx-no-clients","title":"xxx","status":503,"detail":"xxx"}

... the content is definitely returned to curl...

Curl reports:

error code 56, "Received HTTP code 500 from proxy after CONNECT"

I expected the following

So, this "error code 56" is apparently not an HTTP error code because (1) HTTP error codes are defined as 3 digits and (2) I cannot find any reference to HTTP error code 56 (including at https://en.wikipedia.org/wiki/List_of_HTTP_status_codes, https://en.wikipedia.org/wiki/List_of_HTTP_status_codes, or https://datatracker.ietf.org/doc/html/rfc7231#section-6).

In usr/include/asm-generic/errno.h we have:

#define EBADRQC         56      /* Invalid request code */

I do see that Chrome takes a similar approach to reporting a proxy error.

Thus, while I do understand the point made by @dfandrich, by that logic, neither is the 503 "what the transfer is about" yet it is in fact reported by curl (even if encapsulated by the message into an error code 56). The 503 error and its associated headers is what's actually returned by proxies in the HTTP envelope, as proven by tcpdump and (importantly) emitted by -I output. I.e., -I shows the headers of the proxy connection not the content connection.

It seems the standard leaves open the possibility for proxies to return content together with an error response; and curl does pass through the 503 headers with -I. Therefore, the issue may be as much about what facilities curl wants to provide as what the standard says. I suspect it may be silent on this point, but I have not chased that down.

Even though the 503 is "not what the transfer is about", it's relevant to the transfer that was requested and I would argue curl should provide a mechanism to pass that content through. Ultimately, the fact is that proxies "can" return data with a proxy sourced error ("can" as in it's provably technically feasible and does occur in the wild, per google searches). That being said, I did not chase down the full spec on HTTP CONNECT to see if there may be a "MAY NOT" statement about body content (but I doubt it).

That being said, if I'm not mistaken, the spec at https://datatracker.ietf.org/doc/html/rfc7231 clearly shows that content may be returned in any HTTP response bearing any status code, including 503.

Therefore, I would argue that it is appropriate to pass through the body even for errors generated by a proxy or, failing that, that there should be a mechanism for retrieving that content (an additional flag? inclusion in -w %{json}? etc) and/or reporting of that content (or at the very least, that the content exists) in the same message that says "error code 56"

The current behavior can be rather frustrating, when you see that the content-length !=0, yet there's no apparent content, and the only way to see it is via tcpdump.

curl/libcurl version

curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.12
Release-Date: 2022-01-05
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 NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

operating system

all