Caddy 0.9 beta version available [UPDATED beta 2]

It doesn’t seem to make a difference, there is still a 404. What’s probably happening is that once Caddy has matched a request with a server block, it won’t ever try to match with any other server block.

1 Like

You’re correct. Site definitions are completely distinct/independent and one does not roll into another.

Order of the sites in the Caddyfile does not matter; the most specific match will be used.

1 Like

I like the simplicity of this. Things would get complicated quickly otherwise.

1 Like

Can we have a build tag to exclude quic support built in? Not sure if it will make a significant difference, but it kinda adds a lot of packages to the dependency tree.

From my perspective, I anticipate QUIC support will eventually land without being an experiment, so build tags wouldn’t really be useful (it would be like building Caddy without importing the crypto libraries if you only wanted to serve HTTP). I probably won’t spend the time to refactor for it, especially since I’m not really convinced there’s any benefit there.

0.9 beta 2 released

Caddy 0.9 beta 2 fixes a number of bugs reported in beta 1, including fixing a design flaw which incurs a slight breaking change for plugins (sorry, but at least it’s just a few bytes).

Anyone using Caddy 0.9 beta 1 should upgrade to beta 2.

Beta 2 is still known to have some bugs. In particular, we’re going to be closely examining the semantics of the startup/shutdown callbacks during restarts as well as some behavior in the proxy middleware.

Important instructions for plugin authors

This beta has slight breaking changes you need to be aware of.

Change httpserver.GetConfig(c.Key) in your setup functions to httpserver.GetConfig(c).

Your tests for a directive’s setup function may need updating; the signature for caddy.NewTestController() has changed slightly. The instructions for converting your plugin to the 0.9 API and other pages on the wiki have been updated to reflect these changes.

Stay tuned for the next beta versions; it is likely there will be one more breaking change, related to the Startup/Shutdown functions. Sorry about this, but we want to make sure we get them just right. With 0.9’s new architecture, the semantics of what constitutes a startup or shutdown event are fuzzier, and we need to make that clear.

Speaking of events, I’m looking at adding a custom, hopefully simple pub-sub package for Caddy in preparation for its API planned for 0.10. This will make it possible to get live-updating dashboards in API clients as well as a number of other benefits in the capabilities of plugins. It’s still unclear whether this model will affect the 0.9 OnStartup/OnShutdown functions currently used in some of your setup functions.

Feedback

Anyway, thanks for trying Caddy 0.9 beta! Looking forward to your feedback, especially if there are bugs. I also am interested in knowing what you like about it or what confuses you. Keep me in the loop!

1 Like

I’ve been successfully using above configuration with Caddy 0.8.3 to proxy connections to nginx back-end, but on 0.9 beta 2 the first site accessed is subsequently loading for all sites accessed thereafter.

I’ve changes proxy_header to the transparent keyword, but still seeing same behaviour. Is there anything additionally I need to change for compatibility.

I’m not sure I really understand what you mean. What’s your Caddyfile?

Thanks for the reply.

For example:

After Caddy 0.9 beta 2 start, I access site3.example.com - the site successfully loads. I then access site1.example.com but site3.example.com is being served on site1.example.com domain. The first site I access after Caddy 0.9 beta 2 start will subsequently load for any other domain accessed thereafter.

Here is my Caddyfile:

Caddyfle:

:443
bind 10.0.0.8

tls /etc/caddy/cert-VPd3Ea /etc/caddy/cert-VPd3Ea

proxy / https://10.0.0.12:443 {
    insecure_skip_verify
    proxy_header Host {host}
    proxy_header X-Real-IP {remote}
    proxy_header X-Forwarded-For {remote}
    proxy_header X-Forwarded-Proto {scheme}
}

Well this Caddyfile is telling Caddy to proxy all requests on port 443 to a single backend at 10.0.0.12.

Yes, that is correct.

Note on Caddy 0.8.3 it is working correctly and connects to the correct website. On Caddy 0.9 beta 2 it loads the incorrect website on subsequent requests. It is almost if the host header is not being updated on the subsequent requests.

I’m not sure I understand how it’s working in 0.8.3 then; you’re telling all sites on :443 to be proxied to 10.0.0.12, there’s nothing routing site1.example.com to a different backend, for example.

I’m using proxy_header Host {host} to tell the nginx back-end which site to connect to.

Ahh, the sites are routed by nginx in the back. Got it.

Thanks for clarifying, I’ll see if I can reproduce this. We’ve got a few reports of issues with proxy.

@eleshar I think, thanks to help from Maxime, that we’ve found the reason your issue is happening. I’ve pushed a commit to master, if you want to try it now (you’ll have to run from source), but either way Maxime and I are going to keep looking into the strange proxy bugs that have been reported recently!

1 Like