@revel/core Do we really want Revel handling this level of HTTP? We need to decide now how deep down the rabbit hole we're going to go.

If Revel doesn't offer these features, then a proxy like nginx could. We could support fcgi or some environment variable passing for things like HTTP host.

Thoughts?

See #549.

@mcheng89 Sorry to be critical of this PR when I wasn't with #500, but I want to make sure this is really going to add value to Revel for more than just a few developers.

Can you give some sample code demonstrating how this feature would be used given a couple example domains? How would domains be specified in the app routes and to which controllers would it be routed?

Thanks.

Again, I think * should be implied/default so you don't have to edit all the tests and examples. Sorry, looks like you already did that!

Besides that, I think this feature is reasonable, since it means that you don't need to run several Go processes to service a single site with multiple subdomains.

Why is this closed @mcheng89 ?

Anything I could do to help with getting this merged?

Remove method from routepath and have it manually checked after route path is matched. See #1212

Guy what happened with this MR?
This is really a great feature!

We deferred this because we wanted to abstract the server engine, and we wanted to ensure the implementation would be backwards compatible with existing source trees. It is still open because we want to implement this at some point.