On Wednesday, 5 March 2014 14:04:51 UTC-8, Erik van Zijst wrote:
>
> I'll follow up with a pull request, unless there are string feelings, or
> unwanted consequences of that approach.
>
https://github.com/django/django/pull/2401
Cheers,
Erik
>> The relevant django-developers discussion is her
On Sunday, 2 March 2014 05:58:37 UTC-8, Sam Lai wrote:
>
> It seems like the fix makes it easier for 90% of the uses, but
> explicitly blocks the other 10% (i.e. uses involving the use of
> 'reserved' characters as permitted by the RFC).
>
Yes. I'm bringing this up because it breaks certain OAu
I wasn't expressing an opinion either way; just adding the relevant
commit to the conversation.
Looks like RFC 3986 is the relevant RFC describing the permitted
characters in URIs, specifically section 2.2 and 2.3 -
http://tools.ietf.org/html/rfc3986#section-2.2
It seems like the fix makes it eas
On Sat, Mar 1, 2014 at 2:41 PM, Sam Lai wrote:
> The relevant commit and issue -
>
> https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7
> https://code.djangoproject.com/ticket/13260
Yes I saw that, but I'm confused. I thought these characters are
allowed unescaped in
The relevant commit and issue -
https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7
https://code.djangoproject.com/ticket/13260
On 1 March 2014 17:26, Erik van Zijst wrote:
> Django's django.core.urlresolvers.reverse() seems to have changed its
> behavior in 1.6. It
Django's django.core.urlresolvers.reverse() seems to have changed its
behavior in 1.6. It now runs the arguments through quote(), without
specifying the safe characters for path components. As a result:
on 1.4.10:
In [2]: reverse('test', args=['foo:bar'])
Out[2]: '/foo:bar'
but on 1.6.2:
In [2]
