[SOLVED] Passing more options to the embedded Caddy server?

Pydio Cells
1

Hi there,

I’ve been taking a look at the code to try to understand how exactly options are being passed to the embedded Caddy server. This is because, although a ‘standard’ Caddy installation will always reply with HTTP/2 (that’s the default), for some reason, Pydio Cells is answering with HTTP/1.1 (as far as I can test it). Because under Caddy HTTP/2 must be explicitly turned off, I wonder if that’s what is being done — somewhere deep in the code — and, if so, is there a reason why?
As far as I could understand the code reading the pydio.json configuration file (most of which under github.com/pydio/cells/common/config), it seems that the only options forwarded to the embedded Caddy server are those under cert, i.e.

        ssl := Get("cert", t, "ssl").Bool(false)
        selfSigned := Get("cert", t, "self").Bool(false)
        certFile := Get("cert", t, "certFile").String("")
        keyFile := Get("cert", t, "keyFile").String("")

Is there any (simple!) way to add further options to be passed along to Caddy? I understand that something like passing alpn h2 ought to do the trick, i.e. preventing HTTP/1.1 connections to be established and solely rely on HTTP/2.

I understand that I could accomplish this by having a front-end for Cells (say, a separate Caddy, or pound, or nginx, or any of a gazillion reverse proxies that can be found…) but that misses the point… I want to take advantage of Cells’ built-in Caddy server!

2

After a bit of careful digging, I found out a way to ‘fix’ this!

Under gateway/proxy/plugins.go, around line 191, inside func init() you’ll come across the following line:

httpserver.HTTP2 = false

Switching it to true and rebuilding Cells will most definitely get Caddy to reply with HTTP/2!

Now my next question is: why was HTTP2 support deliberately disabled? I guess there might be a reason for that — maybe some internal parts of Cells will stop working? So far, as far as I can test things more or less thoroughly, things seem to be working… although with some console errors on the browser (but I can’t say if these weren’t already present!).

Perhaps there is a good reason why you cannot pass more options to Caddy… namely, those that have been hard-coded (such as lack of HTTP/2 support!) are known to work. Is that the reason?

3

Hi,
I’ve been looking at that very recently: at one point we disabled HTTP2 deliberately because there was an issue with WebSockets support.
But from what I read from the Caddy github issues (and you pointing to alpn instructions seems to indicate you looked at the same stuff), this should now be working, thanks to evolutions of the underlying net library of Go. Not thoroughly tested yet, but we’ll probably remove this line at one point.
That said, I think it could be a great feature request to have the ability to declare additional caddy directives to be launched by the embedded server (without having to recompile everything).
-c

1 Like
4

Sure, I’ll be happy to add that request on GiHub! :slight_smile: