#28883 closed Cleanup/optimization (fixed)
Document that the uuid URL path converter requires lowercase letters
Reported by: | Jean-Daniel | Owned by: | Daniel Leicht |
---|---|---|---|
Component: | Documentation | Version: | 2.0 |
Severity: | Normal | Keywords: | uuid |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
According to RFC4122:
Each field is treated as an integer and has its value printed as a zero-filled hexadecimal digit string with the most significant digit first. The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.
Actually, when trying to parse uuid using the url dispatcher's "uuid path convert", it returns URL not found for anything but lower case UUID, which is surprising as they should be case insensitive.
The uuid path converter should be updated to support upper, lower or even mixed case UUID, as long as they are properly formatted.
Change History (10)
comment:1 by , 7 years ago
Description: | modified (diff) |
---|
comment:2 by , 7 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
If the converter claims to catch UUIDs it has to be compliant with the RFC
comment:4 by , 7 years ago
If the converter claims to catch UUIDs it has to be compliant with the RFC
I don't think the purity argument is strong enough to discard Tim's concerns about URL unicity.
Please chime in on the thread he pointed to in order voice your concern about case sensitivity. This ticket tracker doesn't get enough exposure to justify reverting a recent decision made by the community.
Thanks.
comment:5 by , 7 years ago
As far as I understand their decision was to remove support for the general use of case insensitive URLs by using the Lmsu flags.
If the author has a special use case (like matching a UUID) he can still use a regex like "[a-zA-Z]+" to match it.
Btw, the string, slug & path converters were already case insensitive:
class StringConverter: regex = '[^/]+' def to_python(self, value): return value def to_url(self, value): return value class SlugConverter(StringConverter): regex = '[-a-zA-Z0-9_]+' class PathConverter(StringConverter): regex = '.+'
follow-up: 7 comment:6 by , 7 years ago
The other converters accept upper- and lowercase, but they are not treated the same in general. E.g. DetailView does a case-sensitive lookup for the slug, so /some-slug/
and /Some-Slug/
do not refer to the same database object.
You can quite easily override the UUID converter project-wide to accept upper- and lowercase UUIDs:
class CaseInsensitiveUUIDConverter(UUIDConverter): regex = '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}' register_converter(CaseInsensitiveUUIDConverter, 'uuid')
comment:7 by , 7 years ago
A clean enough solution for my use case.
That said, I think the uuid converter documentation should be updated to make it clear it expects lower case UUID (some people may need to parse upper case UUID and don't get why it fails).
comment:8 by , 7 years ago
Component: | Core (URLs) → Documentation |
---|---|
Has patch: | set |
Summary: | uuid URL path converter failed if UUID is anything but lowercase → Document that the uuid URL path converter requires lowercase letters |
Triage Stage: | Unreviewed → Accepted |
Type: | Bug → Cleanup/optimization |
I'm not sure this change is desirable, at least for everyone, as that would permit many URLs (all case combinations) to map to the same page. A django-developers discussion didn't yield any objections to removing support for case-insensitive URLs (via
(?i)
in URL patterns).Also, with the current architecture URL converters, I don't think it's possible to implement this.