Caddy reverse proxy sets content-type

1. Caddy version (caddy version):

v2.4.6 h1:HGkGICFGvyrodcqOOclHKfvJC0qTU7vny/7FhYp9hNw=

2. How I run Caddy:

a. System environment:

Red Hat Enterprise Linux Server release 7.8 (Maipo)
caddy binary, configured to reverse proxy to webserver on localhost
Python (uwsgi) based web server running on localhost

b. Command:

./caddy_linux_amd64 run

c. Service/unit/compose file:


d. My complete Caddyfile or JSON config:

(common) {
    header /* {
    header Customer-Header "Test"
    header -Content-Type
    header Content-Type "application/octet-stream"
    header /* Content-Type application/octet-stream
} {
  reverse_proxy {
  import common

3. The problem I’m having:

Using Caddy as reverse proxy adds Content-Type (and incorrectly which causes page rendering issues):

curl -k -I -X GET

HTTP/1.1 200 OK
**Content-Length**: 33604620
**Customer-Header**: Test
**Last-Modified**: Tue, 05 Apr 2022 23:37:09 GMT
**Date**: Thu, 07 Apr 2022 04:34:03 GMT
**Content-Type**: text/plain; charset=utf-8

Using nginx as reverse proxy has no Content-Type:

curl -k -I -X GET
HTTP/1.1 200 OK
**Server**: nginx
**Date**: Thu, 07 Apr 2022 05:03:50 GMT
**Content-Length**: 33604620
**Connection**: keep-alive
**Last-Modified**: Tue, 05 Apr 2022 23:37:09 GMT

Direct from the source:

curl -k -I -X GET
HTTP/1.1 200 OK
Content-Length: 33604620
Last-Modified: Tue, 05 Apr 2022 23:37:09 GMT

4. Error messages and/or full log output:

2022/04/07 15:03:36.029 DEBUG tls.handshake choosing certificate {identifier:, num_choices: 1}
2022/04/07 15:03:36.029 DEBUG tls.handshake default certificate selection results {identifier:, subjects: [], managed: true, issuer_key: local, hash: 5da828271d718dd03d564403606794874d94662da1bd55a346fb8012ef16a0b1}
2022/04/07 15:03:36.029 DEBUG tls.handshake matched certificate in cache {subjects: [], managed: true, expiration: 2022/04/08 00:16:42.000, hash: 5da828271d718dd03d564403606794874d94662da1bd55a346fb8012ef16a0b1}
2022/04/07 15:03:36.034 DEBUG http.handlers.reverse_proxy upstream roundtrip {upstream:, duration: 0.001414629, request: {remote_addr:, proto: HTTP/1.1, method: GET, host:, uri: /static/dist/libs.chunk.js, headers: {X-Forwarded-For: [], User-Agent: [curl/7.80.0], Accept: [/], X-Forwarded-Proto: [https]}, tls: {resumed: false, version: 772, cipher_suite: 4865, proto: http/1.1, proto_mutual: true, server_name: }}, headers: {Content-Length: [33604620], Last-Modified: [Tue, 05 Apr 2022 23:37:09 GMT]}, status: 200}
2022/04/07 15:03:36.036 ERROR http.handlers.reverse_proxy aborting with incomplete response {error: write tcp> write: connection reset by peer}

5. What I already tried:

I tried Caddy using http (non-https) too.
Note, the ERROR in the debug output seems to only show when I use the specific curl command with -I to show headers.
If I use:

curl -k

The debug output is:

2022/04/07 15:12:21.899	DEBUG	http.handlers.reverse_proxy	upstream roundtrip	{"upstream": "", "duration": 0.000999075, "request": {"remote_addr": "", "proto": "HTTP/1.1", "method": "GET", "host": "", "uri": "/static/dist/libs.chunk.js", "headers": {"X-Forwarded-Proto": ["https"], "X-Forwarded-For": [""], "User-Agent": ["curl/7.80.0"], "Accept": ["*/*"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "http/1.1", "proto_mutual": true, "server_name": ""}}, "headers": {"Content-Length": ["33604620"], "Last-Modified": ["Tue, 05 Apr 2022 23:37:09 GMT"]}, "status": 200}

6. Links to relevant resources:

Your upstream app should set a correct Content-Type header.

1 Like

Francis’ answer is most correct.

You could probably also overwrite the implicit Content-Type with your own by deferring the header op or setting header_down subdirective in reverse_proxy instead of using the header directive.

This topic was automatically closed after 30 days. New replies are no longer allowed.