puma / puma-dev

A tool to manage rack apps in development with puma

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Confirm, test, and document subdomain support

nonrational opened this issue · comments

foo.hipuma.test, bar.hipuma.test, and hipuma.test should all resolve to hipuma.

The functionality described by 3f601b0 and tested in 2aed6ee actually works pretty reliably for me and is important for my use case.

FWIW, anecdotally, I've found that the behavior works as described in the README when using symlinks to point to directories, but does not work when using the "proxy" support by writing a file with a host/port.

#285 (comment)

Ok so I started looking into this briefly and I realized that in my previous comment I was wrong about the functionality described by the README in 3f601b0 being related to the test in 2aed6ee Edit: After revisiting this I think I was right to conclude originally that those commits are related. It's important to be able to strip the TLD off of Host headers that use subdomains as a prerequisite for being able to use subdomains at all (whether the subdomain points to a distinct app from the main domain or not)

The subdomain functionality as described by 3f601b0 doesn't appear to have any test coverage. Its implementation is in Http.findApp here:

puma-dev/dev/http.go

Lines 82 to 94 in 06bb09e

for name != "" {
app, err = h.Pool.App(name)
if err != nil {
if err == ErrUnknownApp {
name = pruneSub(name)
continue
}
return nil, err
}
break
}

My WIP branch is here: master...cjlarose:test-subdomain-support

I basically just moved the function over to AppPool since that seemed like a more appropriate place for it to live (open to feedback on this), but also tried to make it easier to add unit tests. That's what I'll try to look into adding next.

Opened #289 to add tests for the behavior described in 3f601b0

I took a look also at the test from 2aed6ee, but it's not clear to me actually how it passed previously. My expectation would be that, given the configured TLD .co.test, the domain subdomain.confusing-riddle.co.test should be stripped to subdomain.confusing-riddle, not just confusing-riddle.

Thanks @cjlarose.

That test never passed. I added it to try to ensure we didn't introduce a regression with the new TLD pruning. But, wasn't able to get it to pass and just removed it, incorrectly assuming that the behavior was broken. Turns out the behavior is just fine, but exists elsewhere.

Ok that makes sense! Thanks for clarifying @nonrational