Path Based instead of Host Based

[capitalist]

Do you think it would be possible to wire this up inside a Phoenix app such that example.com/some-path really goes to the upstream instead of some-host.example.com?

[slogsdon]

Most likely, but I'd first want to see how this acts within another Plug-based application, like an application built with Phoenix.

I'll try to take a look soon to see what would be required.

[capitalist]

Roger that. I'll let you know when I get a chance to try this if I get it working.

I want to do it so a Phoenix app can control the domain example.com but example.com/some-path can be reverse proxied to an upstream that doesn't support CORS or JSONP

[slogsdon]

@capitalist, this is definitely possible. Here's a super simple test with a Plug.Router (using the forward/2 macro) and no configuration for the reverse proxy:

The 400 Bad Request response is coming from ReverseProxy as it's the default match for the plug. Also, I did a quick search, and it looks like Phoenix has a similar macro.

There are a few things that need to be improved before this could be useful:

• Allow for a default match. Currently, some sort of compatible :host string is required when configuring the upstreams. This is used at compile time to build the calls to Plug.Router.match/2.
• Unit/Integration tests. Currently, there aren't any. These should also flush out any other improvements/changes necessary.

[capitalist]

This is very awesome. Thanks for that! I'm going to use this to build a web app that is Phoenix up front, with several others in the back. Makes it easy to use each tool at what it's best at.

[elbow-jason]

I would consider adding this to the README or docs. It is very helpful.

[slogsdon]

Will do, @elbow-jason! This was an unintended use case, but it's definitely a useful one.

[slogsdon]

I began an embedding section in the README and will enhance it as the feature is improved.