Unhandled http:// requests for hosts that have auto_https disable_redirects

Help
1

1. The problem I’m having:

I have turned off set the global option “auto_https disable_redirects”, as I do use DNS challenges for letsencrypt and most of my virtual hosts due not need to support http://, but for one of my hosts I need for backward compatibility to support, so this particular host has a config to listen to http;:// explicitly.

This naturally causes caddy to listen to port 80 for all the virtual hosts, not only the one that is explicitly enabled. If caddy does not find a listener, it simply issues the standard access.log message “handled_request” with status 0, which is a little unhelpful. It would be better to have a warning for this case I believe.

2. Error messages and/or full log output:

{
  "insertId": "kj8maafleqnue",
  "jsonPayload": {
    "duration": 0.116915129,
    "user_id": "",
    "request": {
      "method": "GET",
      "uri": "redacted",
      "proto": "HTTP/3.0",
      "client_ip": "redacted",
      "remote_port": "52310",
      "host": "redacted",
      "tls": {
        "cipher_suite": 4865,
        "resumed": false,
        "proto": "h3",
        "version": 772,
        "server_name": "redacted"
      },
      "remote_ip": "redacted",
      "headers": {
        "User-Agent": [
          "redacted"
        ],
        "Accept-Language": [
          "de-DE,de;q=0.9"
        ],
        "Cookie": [],
        "Accept-Encoding": [
          "gzip"
        ],
        "Priority": [
          "u=3"
        ],
        "Accept": [
          "*/*"
        ]
      }
    },
    "size": 0,
    "status": 0,
    "instance": {
      "name": "redacted"
    },
    "logger": "http.log.access",
    "message": "handled request",
    "resp_headers": {
      "Server": [
        "Caddy"
      ]
    },
    "bytes_read": 0,
    "container": {
      "imageName": "jumager/caddy:release",
      "name": "/caddy",
      "imageId": "sha256:f9e476a67182a9c84b63b81fd4151db9c35511a4aaa9eb6dfc690c678be63830",
      "id": "a2c7cd280864d4beba891675fe0f5fc83bb6f6e01a284d8743a881524eb454a0",
      "created": "2024-05-16T14:05:44.984231011Z"
    }
  },
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "https://service.sample.app/url_redacted",
    "userAgent": "redacted",
    "remoteIp": "redacted",
    "latency": "0.116915129s",
    "protocol": "HTTP/3.0"
  },
  "resource": {
    "type": "gce_instance",
    "labels": {
      "zone": "",
      "instance_id": "",
      "project_id": "redacted"
    }
  },
  "timestamp": "2024-05-17T12:45:18.294151671Z",
  "severity": "INFO",
  "logName": "projects/redacted logs/ngcplogs-docker-driver",
  "trace": "projects/redacted/traces/1397404b82f44ecd3862c43d7d9c63c8",
  "receiveTimestamp": "2024-05-17T12:45:19.305970934Z"
}

3. Caddy version:

v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=

4. How I installed and ran Caddy:

Docker with custom modules, see below.

a. System environment:

Various, ARM Ampere and Intel based vservers.

b. Command:

docker compose up -d

c. Service/unit/compose file:

See https://github.com/jum/caddy-docker-proxy-redis`

d. My complete Caddy config:

See https://github.com/jum/caddy-docker-proxy-redis/blob/master/caddy/config/Caddyfile

5. Links to relevant resources:

2

I would say something along the lines of the error message"aborting with incomplete response", just stating that it is unmatched virtual host.

3

I’m not sure I understand why this would be a reason to disable redirects. All it does is have Caddy listen on port 80 so that if someone happens to type the domain in the browser without https:// in front (which browsers default to http://; though that may change in the future), it redirects you to https://.

You should just define a site block that handles it.

Setting auto_https disable_redirects is telling Caddy “yeah I’ll handle it myself if I need to”.

So just add something like this to your Caddyfile:

http:// {
	error 404
}

But still, just leaving on the HTTP->HTTPS redirects is the better option.

1 Like
4

I might have made myself not clear. I am aware of what you said, but I want to avoid listening to port 80 completely. I do still have one site that still explicitly listens for port 80 for compatibility reasons, and that is fine. I will get around in the near future to even turn that off, and if that happens I can turn off port 80 completely. That will be good, as I get a lot of garbage on port 80, mostly probes for security problems.

What confused me, and prompted the initial question is the message that caddy produces if it can not find a host in its config that matches the host header in the http request: namely no real message at all. It just logs an access.log entry with status 0, I think that should be something else.

5

Nope, that’s working as intended.

If there’s an HTTP server in Caddy’s config (e.g. your “one site that still explicitly listens for port 80 for compatibility reasons”), and you disabled redirects, then there’s no other handlers in that HTTP server, so it falls through to Caddy’s default behaviour of responding with an empty 200 status response.

Our opinion is that’s the correct default because “Caddy worked as intended, the request was served as Caddy was configured to handle it”, i.e. no config.

Like I said, if you want a different behaviour than that default, then make an empty http:// site which will act as a fallback for any HTTP request.

But again, I don’t understand why you’d want to avoid using port 80. There’s only downsides to that IMO. Simply serving HTTP->HTTPS redirects to bots or whatever is completely harmless. And the benefit is that any human users using browsers will not see an error if they forget to use https://.

1 Like
6

Actually not an empty 200 response, it is an empty 000 response, that is what confused me.

For me on port 80 I see only junk, no legitimate users.

7

No, it is a 200 status, but the access log shows 0. In Go, 0 is a “zero value” for numeric types, and this results in the default status of 200.

1 Like
8

The above json from the access log shows the status and size as 0, not 200.

9

Once again, the access logs will show 0, but the actual HTTP response is 200. Try it. Make a request with curl -v, you’ll see.

1 Like
10

I have now tried the master version of caddy, and the message was changed, it now logs the message “NOP”, I am fine with that.

11

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