{{{
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/28883>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Old description:
> 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.
New description:
According to [https://tools.ietf.org/html/rfc4122 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.
--
Comment (by Tim Graham):
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
[https://groups.google.com/d/msg/django-
developers/Y51CKkqq6Ng/9DAO7yaVEAAJ 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/28883#comment:1>
* status: new => assigned
* owner: nobody => Daniel Leicht
Comment:
If the converter claims to catch UUIDs it has to be compliant with the RFC
--
Ticket URL: <https://code.djangoproject.com/ticket/28883#comment:2>
Comment (by daniel-leicht):
PR: https://github.com/django/django/pull/9420
--
Ticket URL: <https://code.djangoproject.com/ticket/28883#comment:3>
Comment (by Simon Charette):
> 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/28883#comment:4>
Comment (by Daniel Leicht):
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 = '.+'
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28883#comment:5>
Comment (by Marten Kenbeek):
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')
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28883#comment:6>
Comment (by Jean-Daniel):
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).
--
Ticket URL: <https://code.djangoproject.com/ticket/28883#comment:7>
* type: Bug => Cleanup/optimization
* has_patch: 0 => 1
* component: Core (URLs) => Documentation
* stage: Unreviewed => Accepted
Comment:
[https://github.com/django/django/pull/9429 Documentation PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/28883#comment:8>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"bae365e13c38f0e33b9f00453768de2aac6c727e" bae365e]:
{{{
#!CommitTicketReference repository=""
revision="bae365e13c38f0e33b9f00453768de2aac6c727e"
Fixed #28883 -- Doc'd that the uuid URL path converter matches lowercase
only letters.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28883#comment:9>
Comment (by Tim Graham <timograham@…>):
In [changeset:"be70d3b9687670c7c44cedb4a36476952e5c59d0" be70d3b9]:
{{{
#!CommitTicketReference repository=""
revision="be70d3b9687670c7c44cedb4a36476952e5c59d0"
[2.0.x] Fixed #28883 -- Doc'd that the uuid URL path converter matches
lowercase only letters.
Backport of bae365e13c38f0e33b9f00453768de2aac6c727e from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/28883#comment:10>