#32537 closed New feature (needsinfo)
RequestSite and IDN
| Reported by: | François Poulain | Owned by: | nobody |
|---|---|---|---|
| Component: | contrib.sites | Version: | 3.1 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Without using django.contrib.sites, get_current_site reply a RequestSite instance defining name and domain.
On a IDN setup, we are currently getting Punicode in the name due to the init sequence:
def __init__(self, request):
self.domain = self.name = request.get_host()
IMHO a punicode version of the domain in not what I expect in the name attribute.
I suggest that if any part of the domains starts with xn-- it should be tried to set the name by decoding the domain from idna.
How do you think about it? (I may provide patch if you agree on the behavior)
Change History (3)
comment:1 by , 5 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 5 years ago
| Component: | Uncategorized → contrib.sites |
|---|---|
| Resolution: | → needsinfo |
| Status: | new → closed |
| Type: | Uncategorized → New feature |
comment:3 by , 5 years ago
This is a documented behavior
Ok, thanks for the link.
it's not clear to me why a puncode in name is an issue
I thought it because the models.Site documentation states that name is "A human-readable “verbose” name for the website."
This is a documented behavior:
and get_host() "returns the originating host of the request using information from the ..."
Decoding punycodes would be backward incompatible and it's not clear to me why a puncode in
nameis an issue.