Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow flexible routing with SERVER_NAME config #2813

Closed
jarus opened this issue Jun 1, 2018 · 4 comments
Closed

Allow flexible routing with SERVER_NAME config #2813

jarus opened this issue Jun 1, 2018 · 4 comments

Comments

@jarus
Copy link
Contributor

jarus commented Jun 1, 2018

Expected Behavior

Deployed a flask application which is reachable over multiple domains and ports:

  • external via load balancer: client - Host: example.org -> LB -> flask app
  • internal via DNS service discovery without load balancer: client - Host: instance-1231.example.org -> flask app

If the client connects directly (Host: instance-1231.example.org) the app should be able to return absolute and stable URLs like http://example.org/path/to/my/view as the URL (http://instance-1231.example.org/path/to/my/view) with the internal DNS name is ephemeral.
Therefore I configured the SERVER_NAME config key and url_for generates the intended absolute URL by using _external=True within and without request context. But the app should be still able to route requests coming with Host: instance-1231.example.org.

Actual Behavior

Flasks creates the werkzeug.routing.MapAdapter with server_name=app.config['SERVER_NAME'] and therefore no view method will match to incoming requests with Host: instance-1231.example.org.

Environment

  • Python version: 2.7.13 (I'm sorry)
  • Flask version: 1.0.2
  • Werkzeug version: 0.14.1

Applied workaround:

Overwrite Flask.create_url_adapter and create MapAdapter for request context without server_name parameter. Routing and URL generation works fine.

@davidism
Copy link
Member

davidism commented Jun 1, 2018

Then don't configure SERVER_NAME? It's hard to tell what you're doing because you didn't provide any code.

Please use Stack Overflow for questions about your own code. This tracker is for issues related to the project itself. Be sure to include a minimal, complete, and verifiable example.

@davidism davidism closed this as completed Jun 1, 2018
@killthekitten
Copy link

I had a feeling it was fixed as part of #998. The main issue stays the same – SERVER_NAME has implicit influence on routing, while some people use it only to control url_for.

@davidism described a working solution on Stack Overflow. It involves dropping SERVER_NAME in favor of host_matching=True and @app.url_defaults.

Would it make sense to add the following paragraph from the answer to the SERVER_NAME doc?

However, if you have multiple base domains, you should use host matching instead. You must set host_matching=True on the app object, as well as setting static_host so the static route knows which host to to serve from. Unlike subdomains, you do not set SERVER_NAME. Then pass the host option to routes. This matches against the full domain, and so it requires writing out the full domain each time, rather than just the subdomain.

Docs for host_matching are very modest, at the same time multiple base domains are used pretty often in modern stack, i.e. technical domains on appspot.com (Google App Engine) or heroku.

@davidism
Copy link
Member

davidism commented Jun 5, 2019

Docs PRs are welcome. We shouldn't be cramming routing docs into the config docs though. Either there's a better place in the Flask docs, or the http://werkzeug.palletsprojects.com/en/0.15.x/routing/ Werkzeug docs can be updated.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 14, 2020
@davidism
Copy link
Member

#5634 in Flask 3.1 will further address this. SERVER_NAME no longer affects routing except to determine subdomains if subdomain_matching is enabled.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants