1. Caddy version (
2. How I run Caddy:
Self hosting on a raspberry pi 4.
All working as intended via https following documentation.
a. System environment:
OS: Raspbian GNU/Linux 10 (buster) armv7l
Host: Raspberry Pi 4 Model B Rev 1.4
paste command here
c. Service/unit/compose file:
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
d. My complete Caddyfile or JSON config:
root * /home/USER1/www/tilde-pi.org
root * /home/USER2/www/cosmopostale.tilde-pi.org
3. The problem I’m having:
I would like to only server up .html files and nothing else.
4. Error messages and/or full log output:
5. What I already tried:
Reading up on Matchers & Placeholders, not_file & try_file
I think I am in the right area of thought, but very easily could be way off track.
In my head it seems simpler to allow and serve .html and not *.anything else.
At the moment I can manually, or by script make sure the directories only contain .html files but this allows for human error.
Getting myself a bit tied up in knots.
Happy to look at working examples etc
Many thanks for your time, peace.
6. Links to relevant resources:
I’m not sure I understand. What exactly do you want to happen if a request to a file that isn’t
.html hits Caddy?
I would probably just like the person to be returned to where they were.
So do you mean that you won’t be serving any JS or CSS files at all? Only pure HTML?
Yes, just html & css files.
Apologies the answer is probably staring me in the face.
Okay, then you might do:
@disallowed not path / *.html *.css
redir @disallowed /
So basically, for any requests that are not either to the root of the site (i.e.
/, which will be served by
index.html automatically due to
file_server), or ending in
.css, a redirect back to the root of the site will be served.
This also means any images will not be served (typically important to have, like a
favicon.ico, or whatever).
This seems like a bad approach to me, I think this is a poor attempt at “security”.
Thank you for the example. I will give it a try.
It is indeed an attempt to minimise what can be served etc.
Feel free to expand on “…a bad approach…” or “poor attempt at security”.
I’m always up for learning.
This worked exactly as intended. Many thanks.
To be unambiguous, the proper way to utilize a web server is to only put files in the web root that you actually want to serve.
In this scenario, when someone requests a file that isn’t
.css from your web server, because you didn’t put any such file there, they receive a 404. This is arguably the most “correct” response; it advises the client effectively that you have no such file to give them. This is the default functionality of a web server for this very reason.
Arbitrarily redirecting such requests to the web root index is doable, but not strictly correct behavior (outside of certain contexts, such as SPAs, I guess). It enables you to place non-
.html and non-
.css files in the web root should you wish to, but again, the best and most secure thing to do here to simply not put files in the web root unless you want them served.
Understood, this does make sense.
But what is “bad” about it? I think of bad as introducing something else that could be potentially troublesome.
“Poor” attempt I follow, as what I am asking shows definite lack of knowledge, which I agree with.
To elaborate further, it’s bad for two reasons:
- It’s not strictly correct, when a client requests a resource, for you to redirect them to an unrelated resource.
If they want to ask your web server for some
.jpeg or whatever arbitrary file, issuing a redirect explicitly indicates that the resource they requested is in another location. Redirecting them then to the web root index will end up with some very confused clients who have ended up downloading a HTML document instead of the picture they wanted. A better response is 404, which tells the client you don’t have that resource and can’t give it to them. A slightly better alternative to a redirect would be a 403 (Forbidden), which essentially states that your server is refusing to serve any such resource to the client.
- It encourages bad habits.
Letting you put files in your web root that you don’t intend to serve might be doable safely but it’s a habit that will bite you in the ass if you should ever take the protections you put in place for granted. The only guarantee that a web server won’t serve a file is to not put that file in the web root. Other protections can fail, or be reconfigured by mistake, or you can simply take that habit and apply it mistakenly where it’s not appropriate (e.g. on another web server where those protections aren’t in place).
Thanks! I did end up reading about http server response codes last night, so will for sure start to implement those. That does make sense to me.
This topic was automatically closed after 30 days. New replies are no longer allowed.