Flask

There is a critical caveat when using @blueprint.errorhandler for 404 Not Found and 405 Method Not Allowed exceptions:

These handlers are only invoked if they are explicitly triggered via a raise statement or a call to abort() from within a view function belonging to that Blueprint. They are not invoked when a user attempts to access an invalid URL that does not match any route in the application.

Because a Blueprint does not 'own' a specific URL space, the Flask application cannot determine which Blueprint's error handler to use for an invalid URL.

Recommended Pattern: To implement different handling strategies for 404/405 errors based on URL prefixes (e.g., returning JSON for /api/ routes and HTML for others), define the handlers at the application level using the request proxy to inspect the path.

@app.errorhandler(404)
@app.errorhandler(405)
def _handle_api_error(ex):
    if request.path.startswith('/api/'):
        return jsonify(error=str(ex)), ex.code
    else:
        return ex

You can dispatch requests to different Flask applications based on the first segment of the URL path. This is similar to subdomain dispatching but looks at PATH_INFO instead of the Host header.

Key Differences from Subdomain Dispatching

• Fallback Mechanism: Unlike the subdomain dispatcher, a path dispatcher typically includes a default_app. If the creation function returns None (meaning no specific application exists for that path), the request is delegated to the default_app.
• Path Shifting: When a match is found, the dispatcher should use wsgiref.util.shift_path_info to strip the prefix from the environment before passing it to the sub-application, so the sub-application sees the path relative to its own root.

from threading import Lock
from wsgiref.util import shift_path_info

class PathDispatcher:
    def __init__(self, default_app, create_app):
        self.default_app = default_app
        self.create_app = create_app
        self.lock = Lock()
        self.instances = {}

    def get_application(self, prefix):
        with self.lock:
            app = self.instances.get(prefix)
            if app is None:
                app = self.create_app(prefix)
                if app is not None:
                    self.instances[prefix] = app
            return app

    def __call__(self, environ, start_response):
        # Peek at the first segment of PATH_INFO
        segments = environ.get("PATH_INFO", "").lstrip("/").split("/", 1)
        prefix = segments[0] if segments else None
        
        app = self.get_application(prefix)
        if app is not None:
            shift_path_info(environ)
        else:
            app = self.default_app
        return app(environ, start_response)

# Usage example
def make_app(prefix):
    user = get_user_for_prefix(prefix)
    if user is not None:
        return create_app(user)

application = PathDispatcher(default_app, make_app)

The context follows a stack-based lifecycle. When an activity (like a request) begins, a context is 'pushed' onto the stack, making the proxies available. When the activity ends, the context is 'popped'.

Request Lifecycle Steps

1. The app context is pushed; proxies become available.
2. The appcontext_pushed signal is sent.
3. The request is dispatched.
4. teardown_request decorated functions are called.
5. The request_tearing_down signal is sent.
6. teardown_appcontext decorated functions are called.
7. The appcontext_tearing_down signal is sent.
8. The app context is popped; proxies are no longer available.
9. The appcontext_popped signal is sent.

Note on Teardown Callbacks: Functions decorated with @app.teardown_request or @app.teardown_appcontext are called when the context is popped. They are executed even if an unhandled exception occurred. These functions should be written to be independent of other callbacks, as there is no guarantee regarding the order or state of other parts of the request dispatch.

To create unique Flask application instances for different subdomains (e.g., user1.example.com, user2.example.com), you can implement a custom WSGI dispatcher. This dispatcher inspects the HTTP_HOST environment variable to identify the subdomain and uses an application factory to instantiate the corresponding Flask app.

Implementation Pattern

1. Use an Application Factory pattern to create new instances on demand.
2. Implement a WSGI class that maintains a cache of instantiated applications to avoid repeated creation.
3. Use werkzeug.exceptions.NotFound if a requested subdomain does not map to a valid user/application to ensure a proper 404 response.

Note: This pattern requires the webserver to be configured to route all subdomains to your application.

from threading import Lock
from werkzeug.exceptions import NotFound

class SubdomainDispatcher:
    def __init__(self, domain, create_app):
        self.domain = domain
        self.create_app = create_app
        self.lock = Lock()
        self.instances = {}

    def get_application(self, host):
        host = host.split(':')[0]
        assert host.endswith(self.domain), 'Configuration error'
        subdomain = host[:-len(self.domain)].rstrip('.')
        with self.lock:
            app = self.instances.get(subdomain)
            if app is None:
                app = self.create_app(subdomain)
                self.instances[subdomain] = app
            return app

    def __call__(self, environ, start_response):
        app = self.get_application(environ['HTTP_HOST'])
        return app(environ, start_response)

# Usage example
def make_app(subdomain):
    user = get_user_for_subdomain(subdomain)
    if user is None:
        return NotFound()
    return create_app(user)

application = SubdomainDispatcher('example.com', make_app)