Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#5022 closed Uncategorized (wontfix)

Proposed middleware: SubdomainURLsMiddleware

Reported by: tzellman@… Owned by: nobody
Component: Uncategorized Version: master
Severity: Normal Keywords: enhancement proposal subdomain domain urlconf
Cc: drackett@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX:


I'm developing an application and want to support subdomains. What I had in mind was the ability to support different views depending on the subdomain hit. Essentially, what it comes down to is I want the ability to support separate URL configurations (and thus views) for certain subdomains (known ahead of time). For example, I may have a, where the 'mobile' subdomain deals with urls/views meant for mobile phones.

I noticed issue #4438, and it wasn't exactly what I wanted, or the right solution, so I started researching.

I noticed that in BaseHandler::get_response it attempts to get the 'urlconf' attribute from the request. So, I created a middleware that figures out the subdomain (some code borrowed from, and matches it against a subdomain->urlconf dictionary in And voila! It works! Attached is the file that with the proposed solution.

I am open for critiques/discussion of this topic.

Tom Zellman

Attachments (2) (1.1 KB) - added by tzellman@… 8 years ago.
SubdomainURLsMiddleware (823 bytes) - added by tzellman@… 8 years ago.
updated -- it asumes your Site domain is just the base (e.g.

Download all attachments as: .zip

Change History (10)

Changed 8 years ago by tzellman@…


comment:1 Changed 8 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Example of what you'd change in


    'mobile' : 'mysite.mobile_urls',
    'companyA : 'mysite.companyA_urls',

comment:2 Changed 8 years ago by Max Battcher <me@…>

I appreciate this as a workable solution in some cases, but I don't think it is general enough. This doesn't easily address cases where many/all of the subdomains are sharing a single URLCONF, particularly a deeply nested URLCONF, and yet still need to differentiate content. It also doesn't provide anything in the way of support for standard contrib apps like Flatpages, as there would be no way to have different flatpages appearing on different subdomains solely by modifying the URLCONF.

comment:3 Changed 8 years ago by tzellman@…

Yeah, I agree with you Max. For domains that have at least some overlapping url/view mappings, this solution would require duplication, which is not ideal. This solution satisfies only a small percentage of subdomain needs out there, thus making it not generic enough. However, I think such a "recipe", for lack of a better term, could be useful to some. I guess I'm not actually expecting this to become part of the Django API, but rather wanted to get the discussion started up again, to see if we could draft up a generic solution. I would be more than willing to be a part of such an effort.

Changed 8 years ago by tzellman@…

updated -- it asumes your Site domain is just the base (e.g.

comment:4 Changed 8 years ago by Herbert Poul <herbert.poul@…>

fyi - i have done something similar for my project
but the middleware would also support regular expressions to define urlconfs .. a config would look like:

  r'^(P<groupName>\w+)\.sphene\.net': { 'urlconf': 'sphurlconfs.community_urls', }

all named arguments of the regular expression are then put into a thread local so it can be used by views to further distinguish between the domains. you can see the implementation at ('MultiHostMiddleware')

(i'm using 'Groups' which are similar to the concept of the 'Sites' object in django as they are used to build different sites with different configuration for my wiki and forum apps) - if something like this would be put into django the flatpages application could be easily rewritten to use a thread local to retrieve the current Site object instead of using the settings.

comment:5 Changed 8 years ago by anonymous

  • Cc drackett@… added

comment:6 in reply to: ↑ description Changed 8 years ago by SmileyChris

  • Triage Stage changed from Unreviewed to Design decision needed

Replying to

I noticed issue #4438, and it wasn't exactly what I wanted, or the right solution, so I started researching.

Note that I've put a new ticket up in #4438 which handles the issue a lot better.

comment:7 Changed 8 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

A bit too special-purpose for inclusion in Django, but a good candidate for

comment:8 Changed 5 years ago by ben@…

  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized
Note: See TracTickets for help on using tickets.
Back to Top