PR_END_OF_FILE_ERROR from time to time

[vendelieu]

I have this config:

{
    layer4 {
        :443 {
            @a tls sni othersite.com
            route @a {
                proxy serviceA:443
            }
            @tls tls sni not othersite.com
            route @tls {
                proxy localhost:443
            }
        }
    }
}

site.com {
  // ...
}

sub1.site.com {
  // ...
}
// etc

And I get a PR_END_OF_FILE_ERROR in browser error when refreshing (without cash, ie ctrl+shift+r) from time to time.

The above config works for proxying proxy (lol), which is also sometimes getting terminated.
I noticed that when I change the port from 443 the errors disappear.

The basic idea is this,
at level 4 select by sni request (tcp) and send to the necessary service, the rest of the requests are passed in the processing of the usual caddy proxy.
Also in that terms it's not fully obvious do I need this part:

            @tls tls sni not othersite.com
            route @tls {
                proxy localhost:443
            }

or is it working even without, is it problem related to this... where from this problem come, logs shows nothing related.

[mholt]

If you follow the same patterns of requests using curl, do you get errors?

           @tls tls sni not othersite.com

^ I don't think you need that, since it is implied given the first matcher.

[francislavoie]

Shouldn't it be:

@tls not tls sni othersite.com

The not matcher goes in front, to negate everything that comes after it. Otherwise, it's matching SNI of the value not OR the value othersite.com

[vnxme]

The basic idea is this,
at level 4 select by sni request (tcp) and send to the necessary service, the rest of the requests are passed in the processing of the usual caddy proxy.

You definitely need a listener wrapper then. Inside a listener wrapper you will have only one matcher for othersite.com.

[vendelieu]

Turns out the PR_END_OF_FILE_ERROR problem was related to mozilla's handling of http3.

Isn't there option to disable http3 for mozilla only :/?

[vendelieu]

The basic idea is this,
at level 4 select by sni request (tcp) and send to the necessary service, the rest of the requests are passed in the processing of the usual caddy proxy.

You definitely need a listener wrapper then. Inside a listener wrapper you will have only one matcher for othersite.com.

I've come across listeners wrapper but haven't figured out how to apply it, can you please give me an example of how to use it on a similar config to mine.

[vnxme]

an example of how to use it on a similar config to mine

Try the following:

{
    servers {
        listener_wrappers {
            layer4 {
                @a tls sni othersite.com
                route @a {
                    proxy serviceA:443
                }
            }
            tls
        }
    }
}

site.com {
  // ...
}

sub1.site.com {
  // ...
}
// etc

Please be advised this config will only work with HTTP/1 and HTTP/2. It is a known limitation that it doesn't (temporarily?) support HTTP/3 because QUIC is a UDP-based protocol while the current listener_wrappers implementation in Caddy is TCP-only. In other words, if your browser connects over QUIC, you won't get response from serviceA:443. A related discussion and a workaround of using protocols h1 h2 inside servers directive to turn off QUIC are here.

[vendelieu]

I didn't quite get it, but it seems like after using wrappers the problems stopped appearing sort of :/