Caddy HTTP/1.0 support and disambiguation by interface

1. Caddy version (caddy version):

v2.5.1

2. How I run Caddy:

On a windows machine, multiple interfaces, each of which should be serving exclusively one website (static test for now as proof of concept).

a. System environment:

Windows 10

b. Command:

caddy run

c. Service/unit/compose file:

N/A

d. My complete Caddyfile or JSON config:

192.168.0.106 {
        respond "Hello, interface1!"
}

192.168.0.176 {
        respond "Hello, interface2!"
}

3. The problem I’m having:

I am looking to use Caddy to disambiguate requests coming into an API. The network this needs to operate in is somewhat frustrating in that the API will handle requests on behalf of multiple parties, but the only information I will receive regarding who the request is for is the IP it gets sent to (I will be running many interfaces on one machine). The network in question does not use SNI, and as far as I can find out is using HTTP/1.0 and will not send Host headers.

I’ve tried this using the above configuration, but I cannot get a reply when asking the server:

openssl s_client -connect 192.168.0.106:443
GET / HTTP/1.0

I cannot find anything regarding whether Caddy even supports HTTP/1.0, and if it does if the above scenario is possible to achieve.

4. Error messages and/or full log output:

GET / HTTP/1.0

HTTP/1.0 200 OK
Server: Caddy
Date: Wed, 25 May 2022 07:21:53 GMT
Content-Length: 0

closed

5. What I already tried:

I’ve looked at the bind directive, which seems to at least restrict the interface. It still returns content-length: 0 on HTTP/1.0 requests though.

6. Links to relevant resources:

You put an IP address in the site address location, which sets up Caddy to match the Host header for that IP address. If your client doesn’t sent the Host header, then Caddy won’t match that site block.

You can instead do this, I think:

http:// {
	bind 192.168.0.106
	respond "Hello, interface1!"
}

http:// {
	bind 192.168.0.176
	respond "Hello, interface2!"
}

But I’m not sure if the Caddyfile adapter will be happy with this because technically you end up with duplicate site blocks.

If it complains, then try just with one site block, then run caddy adapt --pretty --config Caddyfile to see the underlying JSON config (the caddyfile adapter’s job is just to transform a Caddyfile config into JSON). That’ll more clearly show you what’s going on. Then you can just write a JSON config the same way, adding the bits you need.

Edit: I just realized you’re trying to use openssl to connect… Yeah I don’t think the Caddyfile will support this usecase at all. SNI is required for certificate selection to work correctly. You could configure the default_sni global option to at least have a default value for SNI, but in the Caddyfile, that’s a global option that will apply to all servers, not isolated by bind. So you’d need to use JSON config to configure tls_connection_policies with a different default_sni per server. You could also play with matching connections by remote IP, see JSON Config Structure - Caddy Documentation

1 Like

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