Wondering if there is a Caddy equivalent to dot-files like in Apache web server?
Where you can override certain directives per folder basis.
If there isn’t, I think this would make a great addition to Caddy. This would allow a certain degree of customization for shared hosting scenarios and others.
I’m not sure how that would work in Caddy. Caddy extensions are written in a specific way where they’re provided with arguments, and the extensions decide whether requests should be intercepted or not based on the configuration they are given. Caddy doesn’t know what each argument represents, it just knows that it’s a value for something. Adding this feature would be quite infeasible, and if it were to happen, would not support many extensions and would require extension authors to re-write their extensions. This also adds a whole new layer of complexity to Caddy, and how extensions would work.
Although such a feature could be useful, I highly doubt it’ll ever happen in Caddy.
If you wish to override directives per directory, Caddy supports paths in site address definitions as of version 0.9+. For example:
example.com/foo {
// your configuration here
}
I didn’t say anything about it being an extension. It may very well need to be something done by Caddy instance upon processing every request. Similar to what Apache does: if overrides are enabled, Apache scans the directory hierarchy up to DocRoot for presence of .htaccess override files.
I doubt that such feature would necessitate changes to existing extensions. Well, it would depend on where in the lifecycle of a request a given extension hooks in. Still, it would be a matter of applying overrides to the config tree (or whatever data structure is used to load/access config info in Caddy) per request being processed. This new state of configuration would then be available to whatever extension(s) being called to process request and go on as normal. Thus as far as extension is now concerned it would be as though Caddy read it’s config from single file at start up.
Unfortunately your suggestion does not solve my use case. I would like to allow end-users some degree of customization without letting them edit main Caddy config file.
Nginx do not support dot-files as well and @1lann’s explanation is quite accurate.
I would suggest we consider other approaches than trying to do it solely the Apache way.
@abiosoft, it’s funny that you wish to “consider other approaches” other than “Apache way”, yet you totes fine with following the Nginx way. So much for “other approaches”. So aside from Let’s Encrypt and HTTP2 support, how does Caddy differ from Nginx now…?
Nginx is geared towards high-performance. Not general purpose. Traversing the filesystem is expensive in terms of performance. I get that. That’s why this option would be optionally enabled. Much like in the “Apache way”. Nginx is a niche web-server catering to high-performance content serving. Usually a front for app/content servers. Where as Caddy appears to be catering to general population (much like Apache).
Quotes from Caddy homepage.
“Other web servers were designed for the Web, but Caddy was designed for humans, with today’s Web in mind.”
“Caddy supports HTTP/2, IPv6, Markdown, WebSockets, FastCGI, templates and more, right out of the box.”
Well, humans want customization. I’m not the only one interested in per-directory or per-domain overrides to main Caddy config. Just look at the other forum threads.
Funny that support for Markdown out of the box is somehow groundbreaking and worthy of front-page mention, but inability to customize part of config on the fly is… an outdated Apache way? Where is Textile support? Where is MediaWiki markup support? /s smh
Furthermore, if you think that @1lann’s explanation is accurate… and I paraphrase, because you can’t seem to think of it done any other way but the extensions way… then you need to get your head out of extension sandbox. This would have to be part of the core of Caddy as I explained above before extensions are bootstrapped.
I didn’t mean to imply that it would be an extension. What I was saying that because directives (which are all actually extensions, even built in ones) are provided with arguments which tells the extension what paths are relevant to it. However there’s no way for caddy to tell which argument is the correct argument for telling the directive the path of configuration. It could be the first argument, or maybe the last. Because of this, it doesn’t make it very clean to configure.
If having Apache’s configuration system is so important for your use case, you should probably stick with Apache. Noone ever forced you to use Caddy, as with anything, there are benefits and drawbacks of using different products.
Caddy is designed for humans, just not designed for all humans’ use cases.
Where is Textile support? Where is MediaWiki markup support?
Caddy is relatively new, you can feel free to add a pull request to add support for it.
Traversing the filesystem is expensive in terms of performance. I get that.
It’s not that traversing the filesystem is expensive, it’s just that Caddy’s core configuration system is not designed to support something like this. There will just unfortunately be too many conflicts to resolve for the feature you’re requesting.
I think, after all the discussion you’ve raised in multiple threads, this is what you ultimately want. How it’s done is less important, really. And I want this too. If Caddy could be easily used on shared hosts, HTTPS use would surge higher for that long, long tail of small sites powered by CPanel or whatever else. Many of the vulnerabilities non-and-less-technical site owners are exposed to would be eliminated.
I recommend writing a wrapper over Caddy to do what you want. This wrapping program can control users, authentication, etc, and enforce certain permissions. Generating a Caddyfile is easy from that point. I suggested something like this a year ago (before Caddy was what it is today, so “middleware” is kind of irrelevant – a wrapper is more fitting now) and would be happy if somebody wanted to build it.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.