Caddy returned a 200 instead of a 304 when the browser accessed the cached page file

Help
1

1. Output of caddy version:

v2.5.2 h1:eCJdLyEyAGzuQTa5Mh3gETnYWDClo1LjtQm2q9RNZrs=

2. How I run Caddy:

a. System environment:

SMP Debian 5.10.136-1 (2022-08-13) 5.10.0-17-cloud-amd64

b. Command:

I execute this command after confirming that caddy is closed

sudo ./caddy start

c. Service/unit/compose file:

Sorry, I don’t quite understand what I need to fill in here. I filled in the content of the output after caddy is started below.

asen@debian:~$ sudo ./caddy start
[sudo] password for asen: 
2022/08/24 08:29:38.537 INFO    using adjacent Caddyfile
2022/08/24 08:29:38.544 INFO    admin   admin endpoint started  {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2022/08/24 08:29:38.546 INFO    http    server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv0", "https_port": 443}
2022/08/24 08:29:38.547 INFO    http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2022/08/24 08:29:38.550 INFO    http    enabling automatic TLS certificate management   {"domains": ["mcpanel.seninter.net", "free.830613.xyz"]}
2022/08/24 08:29:38.562 INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc000202fc0"}
2022/08/24 08:29:38.564 INFO    tls     cleaning storage unit   {"description": "FileStorage:/root/.local/share/caddy"}
2022/08/24 08:29:38.567 INFO    tls     finished cleaning storage units
2022/08/24 08:29:38.624 INFO    autosaved config (load with --resume flag)      {"file": "/root/.config/caddy/autosave.json"}
2022/08/24 08:29:38.625 INFO    serving initial configuration
Successfully started Caddy (pid=8047) - Caddy is running in the background

d. My complete Caddy config:

{
	email deason.hu@gmail.com
}

free.830613.xyz {
	file_server
	root * /home/asen/sub/
}

#cloud.senint.net {}

mcpanel.seninter.net {
	# Web-side reverse proxy target
	reverse_proxy localhost:23333 {
		# Some necessary HTTP Header settings
		header_up Host localhost
		header_up X-Real-IP $remote_addr
		header_up X-Forwarded-For $proxy_add_x_forwarded_for
		header_up REMOTE-HOST $remote_addr
		# Required Websocket support
		header_up Upgrade $http_upgrade
		header_up Connection "upgrade"
		header_down X-Cache $upstream_cache_status
		header_down Cache-Control no-cache
	}
	header * Cache-Control max-age=43200
}

3. The problem I’m having:

When the browser accesses the website, I see the cache control field in the response header. When the file has not changed, when the browser sends a request header containing the If-Modified-Since field, I expect caddy to return 304. This way the browser doesn’t re-download duplicate files to improve opening speed. To this end, I used xcaddy to compile and install caddy, and added two possibly related modules, namely:

My English is not very good and I didn’t understand their documentation, so I didn’t modify the configuration file for this.
I hope that when caddy responds to the request, it can bring the response header etag and last-modified. When the browser’s request header contains If-Modified-Since or If-None-Match, caddy can determine whether to use browser caching.

4. Error messages and/or full log output:

The program is running normally, no errors are reported

5. What I already tried:

I added two mods to build caddy, I hope the default configuration will solve the problem, I describe my approach in detail in “The problem I’m having”.

6. Links to relevant resources:

2

I strongly recommend not using caddy start, but instead running Caddy as a systemd service. And also, I strongly recommend not running as root if possible (i.e. don’t use sudo).

Our docs have instructions for this, depending on how you installed Caddy. It’s easiest if you use our apt repo (since you’re on debian).

When you run with caddy start, you lose all the logs that Caddy writes, because it’s just running in the background with no way to write the logs anywhere for you to check later. And also, it won’t restart along with your system if it need to reboot.

Remove all of this. None of it is necessary.

Most of that looks like you took it from an nginx config, but that’s not compatible with Caddy.

The reverse_proxy directive will set any necessary proxy headers automatically, so you don’t need to do anything here.

The plugins don’t do anything for you unless you use their directives in your Caddyfile.

FWIW, if you do need to run Caddy with plugins while using the apt repo, then follow these instructions to replace your Caddy binary:

Well, if you’re using reverse_proxy, Caddy doesn’t read those headers at all. It’s up to your upstream app to do this correctly. There’s no way for Caddy to be able to check if the served files changed or not, because it doesn’t have access to the files being served.

If you used file_server though, then Caddy would be able to “do the right thing”.

2 Likes
3

hello, caddy doesn’t have permission to access reverse proxy’s files does that mean there’s no way to check if the files are the same even after adding a mod?

4

Exactly. From Caddy’s perspective, that’s impossible.

If you had a config like this:

example.com {
	root * /srv
	encode gzip
	file_server
}

Then Caddy would be looking at files inside /srv and serving them, applying the correct headers and responding with 304 if necessary, plus gzip compressing files as they’re sent.

But using reverse_proxy, there’s no way for Caddy to know where to look for files. The job of reverse_proxy is just to take the incoming HTTP request, and copy it as a new connection to the configured upstream, in this case localhost:23333, then wait for a response, and copy the response back to the client. (Obviously there’s a bit more details like adding in some request headers for this to play nicely, and the bevy of other options on top of that, but that’s the core idea).

1 Like
5

Thank you very much, I understand.

6

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