Share Caddyfile parsing

[miekg (Miek Gieben)]

Hi,

I just had a thought (it has been mentioned before I think), but CoreDNS and Caddy should possibly share the Caddyfile parsing. I wasn’t looking forward into porting and patching up my Corefile parsing, but it seems silly to do so since the syntax is identical. Only the grouping is different, and the name of the file (obviously). Also some validity checks on the top-level names; hosts in Caddyfile, zones in Corefile for instance.

Not sure what the exact API should be, have to dig through the code a bit to check…

[matt (Matt Holt)]

Hey Miek! Good to hear from you.

What do you mean by “share” the parsing exactly?

(Quick preface to rest of answer…) This is the structure of any Caddyfile:

<keys>              |  This whole file is
<directives>        |  a "server block"

or, for multiple blocks in a file:

<keys> {                  |
    <directives>          |  One server block
}                         |
<keys> {
    <directives>
}

As of Caddy 0.9, Caddy assigns no meaning to the keys of a server block. So they can be hostnames or zones or whatever you want. It purely parses structure; your server type can parse the keys and make sense of them (Caddy’s HTTP server does this to know which ports to listen on, for example).

The function that parses the Caddyfile into structured values for you is caddyfile.Parse().

[miekg (Miek Gieben)]

Ah, caddyfile.Parse(), not sure how I missed that. Great! Exactly what I need.

[matt (Matt Holt)]

Note that, if you’re building a server type plugin for Caddy, you don’t need to call that function yourself. Your server type will be handed the parsed results in your InspectServerBlocks() method, for instance. And each directive’s setup function will have access to the key it is being used with.