Opened 15 years ago
Closed 10 years ago
#8896 closed New feature (wontfix)
Routing according also to hostname
Reported by: | veena | Owned by: | jshedd |
---|---|---|---|
Component: | Core (URLs) | Version: | 1.0 |
Severity: | Normal | Keywords: | routing hostname |
Cc: | mike.huynh+django@…, jedie, Gert Van Gool, Florian Apolloner, cg@…, charette.s@… | Triage Stage: | Someday/Maybe |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
There should be a possibility to route urls even according to hostname.
It's quite often especially in blog sites that users get 3rd domain eg. http://username.example.com
In Django url router doesn't take hostname in consideration.
You can write own middleware, where you can rewrite username.example.com to something like example.com/user/username/ in process_request() function. But then function like "reverse()", decorator like "login" or template tag like "{% url %}" are not able to construct whole url with hostname back now.
In case of implementation routing with hostname there could be simple syntax in urls like that:
urlpatterns = ( ('^forum/$', forum) # normal route ('^/(username)\.example\.com/forum/$', user_forum) # route with domain with http protocol ('^//(username)\.example\.com/forum/$', user_forum) # or syntax with double slashes to have a more impact to visibility and parallel to http:// ('^s//(username)\.example\.com/forum/$', secure_user_forum) # route with domain with https protocol )
There should be some enhancement to decouple hostname from route. For example:
('^//(username)\.SETTINGS_DOMAIN_WILDCARDS\.[a-zA-Z]{2-4}/forum/$', user_forum)
Or using some special mark:
('^//(?P<username>)(?site)/forum/$', user_forum) # complete with domain from actual Site or RequestSite object ('^//(?P<username>)(?site=2)/forum/$', user_forum) # complete with domain with ID 2 from Site object
In reverse functions proper url with hostname should be considered.
I think there is need to more clarify all possible circumstances they can occure before implementing of this feature would be start. It could be nice feature in 1.1 version of Django.
Change History (18)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
Triage Stage: | Unreviewed → Someday/Maybe |
---|
comment:4 Changed 14 years ago by
#5034 may address this issue in that reverse() and consequently {% url %} respect the overridden urlconf.
comment:5 Changed 14 years ago by
milestone: | → 1.2 |
---|---|
Owner: | changed from nobody to jshedd |
comment:6 Changed 14 years ago by
milestone: | 1.2 |
---|
comment:7 Changed 14 years ago by
Cc: | mike.huynh+django@… added |
---|
comment:8 Changed 14 years ago by
Cc: | jedie added |
---|
comment:9 Changed 14 years ago by
Cc: | Gert Van Gool added |
---|
comment:10 Changed 13 years ago by
Cc: | Florian Apolloner added |
---|
comment:11 Changed 13 years ago by
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:12 Changed 13 years ago by
Cc: | cg@… added |
---|---|
Easy pickings: | unset |
comment:13 Changed 13 years ago by
You might want to have a look at the django-hosts app: http://pypi.python.org/pypi/django-hosts/
comment:15 Changed 12 years ago by
Cc: | charette.s@… added |
---|
comment:16 Changed 11 years ago by
Component: | Core (Other) → Core (URLs) |
---|
comment:18 Changed 10 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
This has been solved by external apps and I'm happy with that solution.
Django should remain focused on the mainstream use cases.
This one isn't unheard of, but it's hardly common.
There should be (?P<username>) instead of (username) in first two examples.