ICVOSS DJANGO PACKAGE REGISTRY

Home hostmap How it works

How django-hostmap works

django-hostmap is the seam between one Django codebase and many public hosts. A single middleware, HostmapMiddleware, reads request.get_host() on every request, matches it against the HOSTMAP setting, and swaps in that entry's request.urlconf before routing continues. Nothing downstream needs to know which host it is serving.

The other half is reversing. A patched resolver wraps reverse(): it tries the current request's URLconf first, exactly as stock Django does, and only consults the other entries in HOSTMAP when that lookup raises NoReverseMatch. That is why same-host links on this page, such as the one back to the main hostmap demo below, come out relative and byte-identical to what plain Django would produce, while a link to another host's view name resolves through a different entry and comes back as a full absolute URL.

This is also why an unmapped host is not automatically an error: HOSTMAP_UNMATCHED controls whether a request to a host nobody declared falls through to the default entry or is rejected outright. See the "Unmapped hosts" section on the main hostmap page for this site's own answer.

That link is same-host: hostmap leaves it relative, unlike the cross-host links below.

Other live demos

  1. No.01
    django-hostmap (you are here)

    Host-based URL routing and host-aware reversing.

    hostmap.icvoss.com
  2. No.02
    django-icv-tree

    Materialised path tree structures.

    tree.icvoss.com
  3. No.03
    django-icv-taxonomy

    Cross-domain taxonomy, vocabularies, and tagging.

    taxonomy.icvoss.com
  4. No.04
    django-icv-search

    Pluggable search engine integration.

    search.icvoss.com
  5. No.05
    django-icv-sitemaps

    Scalable sitemap and discovery file generation.

    sitemaps.icvoss.com
  6. No.06
    django-brickwork

    A brand-agnostic UI substrate: shell, nav, components.

    brickwork.icvoss.com