Route for subdomains

[alikzao]

Describe

Sometimes there are situations when it is necessary for the current project to create a subdomain just as another rout. And hang on to this subdomain a handler that is already there.

Expected behaviour

For example it might look something like this:

app.router.add_route('GET',  '/',  main_page)
app.router.add_route('GET',  '/',  handler, subdomain="domain")

def handler():
      print('text')

[asvetlov]

After #1301 it's possible to register subapplications by prefix.

I suggest the same technique but for resolving by subdomain.

[cynecx]

I am currently using the approach of adding a custom middleware which specifically filters out unknown hostnames, the only issue I am currently having is that it quite hard to support real micro-services with different domains, but this isn't an issue anymore especially after @asvetlov has landed sub-applications :).

[asvetlov]

I mean we could add a method router.add_subdomain('sub.domain.com', subapp) like recently added router.add_subapp('/prefix', subapp).

[cynecx]

@asvetlov Do you also consider supporting wildcards in the domain name as well a falback so unknown domains are handled too?

[asvetlov]

Why not?

[cynecx]

@asvetlov Well, by looking at your example I thought you would like to keep it very simple, so in that case I assumed it would come without wildcard and fallback domain support. But yeah, it's good to know that you will include that too :).

[ghost]

Is it implemented?

[fafhrd91]

no, it is not

[ghost]

Very sad :(

[fafhrd91]

Would you provide PR?

[ghost]

Nah, I'm not familiar with aiohttp

[alikzao]

@TiberiumPY I did not wait for decisions, so switched to another framework

[ghost]

@alikzao what framework?

[fafhrd91]

You have plenty of options. Pyramid, flask.

[espositofulvio]

If this has not been done yet, I'd like to have add_domain instead of add_subdomain. It would be a nice feature which could easily enable multi-site support for aiohttp applications. Further, having remove_subapp() and remove_domain() would complete the feature allowing to dinamically add and remove features to a website and in my opinion could be a nice thing to have (paid features come to mind but also a multi-site cms where user can actually load the features they want could be handled this way easily).

[alex-eri]

I suggest to rewrite domain to prefix on front web-server (like nginx)

[amirouche]

@alex-eri it doesn't work well outside production, except if you also have to configure nginx on the development host.

[amirouche]

I am willing to work on this.

I mean we could add a method router.add_subdomain('sub.domain.com', subapp) like recently added router.add_subapp('/prefix', subapp).

And prolly:

wildcards in the domain name as well a falback so unknown domains are handled too

[amirouche]

To be perfect, aiohttp needs a replacement for eoe:

*.hostname.local dns resolver, pow.cx replacement wanna-be.

[asvetlov]

To be perfect, aiohttp needs a replacement for eoe:

Sorry, I don't follow

[amirouche]

Sorry, please forget about the eoe thing.

[mlyko]

Hi there,

I'd like to ask you if you going to add this feature to the aiohttp official release at all? I'm asking because the corresponding pull request seems to be abandoned by an author.

And second question. Why don't you want to add an ordinary routing by the 'Host' header to aiohttp, like it is available almost in all modern web framework (e.g. tornado, sanic)? Like this: router.add_route('GET', '/path/', handler, host='example.com')

I could provide an appropriate pull request.

[asvetlov]

Currently nobody works on the feature AFAIK but we very appreciate the contribution.

Regarding to second question (router.add_route('GET', '/path/', handler, host='example.com')). I think it is not necessary: the code mixes routing by host and bare requests. Maybe better to support explicit sub-app with host (domain) specified.

[mlyko]

Sorry, but I don't get it, what do you mean writing that 'the code mixes routing by host and bare requests'? Please take a look at a concept of such routing which I've already implemented: https://github.com/mlyko/aiohttp/commit/9054d0b6f2ab69b42d80e5f6d8642a19e6d09382 and give a feedback.

I don't like the concept with sub-apps in this case because I'll have to create sub-apps to use the routing by host feature. Whereas sub-apps in aiohttp are for solving problem with big projects, not for routing purposes.

[asvetlov]

Now in aiohttp router is conceptually a table of regular expressions (let's assume that PlainResource can be converted to regex easy). It allows future optimizations like https://github.com/pyrates/autoroutes or https://github.com/intel/hyperscan to replace iteration over resources with single call to highly optimized structure for a set of pre-compiled regular expressions. Adding a host to resource match criteria complicates such optimization.

I prefer to have a route table per host.

[mlyko]

Ok, thanks for clarifying. So it means that futher developing an implementation of routing by host proposed by me doesn't make any sense :)

[asvetlov]

But explicit domain/subdomain support does make sense :)

[roganov]

It's probably a little tricky, but route and subdomain rules can be combined in a single regular expression. I believe werkzeug does this.

[asvetlov]

I pretty sure the combining is an implementation artifact, not the main intention. As an alternative we can consider NGINX (or Apache) config. The config has server and location directives, pretty easy and understandable.

[samuelcolvin]

I believe this should have been closed by #2809