Caddy file directive, parse error?

(Caleb Fong) #1

I’m setting up a local dev environment on my Windows 7 workstation. Nothing crazy just a way to make sure scripts pulled in through a <script> tag load as expected.

I’m using what I believe to be correct for my caddyfile based on the docs here –

# This is a super dumb caddyfile

http://jQuery.test { # naturally not a real TLD but no matter how this changes I get a parse error when I run caddy on the commandline
  root c:\tools\jQuery_exp # this has an index.html so it should show something

The text of the error:

2019/03/06 11:45:03 Caddyfile:3 - Error during parsing: Unknown directive 'http://jQuery.test'

I looks like I can stack the site definitions, but the parse error above is ever present. :face_with_raised_eyebrow: I’m sure I’m missing something, but I’m not certain what.

Addendem - 2019-03-06-1227

I also tried the following in the caddyfile and got past the parse error but still didn’t get to my index file

http://jQuery.test:8888 {
  root c:\tools\jQuery_exp

– 2019-03-06-1240 –

I was looking a few other caddy files here on the forum and though I’d try one more thing

  jQuery.xxxxxx.test {
    root c:\tools\jQuery_exp

and got the following response:

2019/03/06 12:39:18 Caddyfile:2 - Error during parsing: Unknown directive 'jQuery.calpet.test'

Ok one last thing then I’ll stop for awhile.

Tried this caddyfile:

http://jQuery.calpet.test {
  root c:\tools\jQuery_exp
  proxy / localhost:8000 {

No parse error! :smiley:
But the output at the terminal says:

λ caddy
Activating privacy features... done.

Serving HTTP on port 80

But I told it to be on port 8000 :confused:

(Conor Burns) #2

do this:

http://jQuery.calpet.test:8000 {
  root c:\tools\jQuery_exp
  proxy / localhost:8000 {

happy hacking :smiley:

(Caleb Fong) #3

Thanks! That does parse correctly.

The browser is still coming back with “Server not available”. :roll_eyes:

Side note, I’m sure I could move the caddy.exe to the working folder, but as I understand it, I shouldn’t have to.

(Matthew Fay) #4

Hi @C_Fong, I’m going to try to elaborate a little bit on what was likely to be causing your issues.

In your initial question:

To quote from that document:

To configure multiple sites with a single Caddyfile, you must use curly braces around each one to separate their configurations:

Notably, :8888 doesn’t have a curly braced block, and so you have not used curly braces around each one.

If there was a file called c:\tools\jQuery_exp\index.html (or perhaps index.htm or index.txt), Caddy should have served it if you navigated to http://jQuery.test:8888 in your browser. If the file exists, and it wasn’t served, there’s another issue at play that might need to be investigated.

This is called nesting, and the Caddyfile does not support nesting sites within sites (or directives within directives, for that matter).

Each site must be at the top (left-most) level of the Caddyfile.

@conorlburns picked up the fix for this one somewhat, but to elaborate, you didn’t tell Caddy to serve port 8000; you told Caddy to serve the default HTTP port (by specifying http:// but leaving out a port in the site label).

It looks like, instead, you told Caddy to proxy to localhost on port 8000. That means when you connect to Caddy and request http://jquery.calpet.test, Caddy connects to its own localhost on port 8000 and returns the result to you.

This might come back here…

It looks like you have Caddy proxying to itself. It’s listening on port 8000 and proxying to port 8000. Looking at the configuration offered by @conorlburns, I would expect to see Site is not served on this interface to be the result.

This is a classic case, I think, of overthinking the Caddyfile. Lets get back to basics: What do you want Caddy to do for you, in plain English?

(Conor Burns) #5

Uhh I think I might know why this is not working…
jQuery binds to 8000 and caddy takes that and sends it over 8000

Edit: dang it I’m to slow xD
Edit2: sorry didn’t think that one through but at least the principle was right :sweat_smile:

(Caleb Fong) #6

Overthinking is one of may hallmarks. :grimacing:

I need to load an html file into the browser from a server to better test javascipt.

I’d like to have subdomains or just names, for the different sets of experiments I’m running. I’m testing out some frameworks and some vanilla JS implementations. With the end goal of making some internal tools for my co-workers.

I don’t need SSL (yet) and proper TLD extensions (.com) are also not needed (yet).

Thanks for your help!

@conorlburns - No worries, mate! You at least got me past the parse problem :wink:

(Matthew Fay) #7

Cool, I think this should be pretty straightforward. Here’s my recommendation:

  • Structure your folders so that each different experiment has its own folder on disk
    i.e. C:\www\jquery_1, C:\www\jquery_2, etc.

  • Rename each experiment’s HTML file to index.html
    i.e. C:\www\jquery_1\index.html, C:\www\jquery_2\index.html, etc.

  • Repeat simple Caddyfile blocks for each experiment:

http://jquery_1.calpet.test {
  root C:\www\jquery_1

http://jquery_2.calpet.test {
  root C:\www\jquery_2

Bonus round (going right back to overthinking :smiley:), if you get that working, you can look into using a single Caddyfile block:

http://*.calpet.test {
  root C:\www
  rewrite {
    to /{label1}{uri}

This one uses magic to serve the index file in the folder that corresponds with the subdomain you requested, for any arbitrary subdomain. Then you can just add or remove folders in C:\www without needing to change the Caddyfile or restart Caddy.

(Caleb Fong) #8

Thanks so much!

I’m still getting an error but it opening the page in Opera gave me a different error page and I think the issue is DNS – rexponse text DNS_PROBE_FINISHED_NXDOMAIN

(Matthew Fay) #9

Yep, that’s DNS. Does your local DNS resolver return the loopback IP for .test domains?

I do this with a service on my macOS development machine (more details here: [Guide] Local web development setup on a Mac). You might need a similar solution, or control over your network’s DNS resolver to give this capability to all machines on your network.

(Caleb Fong) #10

At this moment we don’t have a local resolver. Getting one set up is on my todo list – which is getting very long since I do several different jobs. I appreciate the link, but sadly I’m on Win 7 so I don’t have Homebrew.

A quick search turned up which is written in dotNet so I’m gonna try that first and then maybe spin up a BSD instance and put dnsmasq or something there.

(Gorian) #11

If you need something quick to test .test for development purposes (and you shouldn’t be using a non-IANNA registered domain for anything else anyway, externally or internally), you can edit your hosts file, found in windows at C:\Windows\System32\drivers\etc\hosts, and add a line like test.calpet.test

If you aren’t familiar with the hosts file, you basically make manual mappings of IPs to DNS names, it overrides DNS resolution, perfect for testing.

A few things to note:

  • you have to run your editor, such as notepad.exe, as an administrator in order to edit the hosts file
  • make sure that you remove or comment out your entries when you are done, or down the line you’ll spend a lot of time wondering why your DNS isn’t resolving because you’ve forgotten about your hosts entries

(Caleb Fong) #12

Ok, that works for a quick and dirty test, thanks @Gorian . :slight_smile:

I think I’m gonna end up setting up dnsmasqe, since I need to upgrade the dhcp server anyway.

::sigh:: DNS is kinda complicated. (he said, stating the obvious)