2012/12/18 Karen Tracey <kmtra...@gmail.com> > https://code.djangoproject.com/ticket/5738 > > Comment #10 notes that utf-8 is what Django will use but with the last fix > noted against that ticket it is easier for the request class to be > subclassed to change things for an installation where a different charset > for decoding might be desired.
Hi Karen, Indeed, thanks. I reviewed that ticket and I agree with the final fix. Sure, it's a bit sloppy to use a protocol-level message for an application-level requirement (in other words, to reply to a well-formed HTTP request with 400 Bad Request), but I can't think of a better solution when the URL cannot be decoded with the "expected charset". Now, I'm proposing something slightly different. I think that the "expected charset" to be DEFAULT_CHARSET rather than "utf-8". If the URL cannot be decoded, the error handling designed in #5738 would still kick in. I consider that Django already "strongly recommends" utf-8, as it's the default value of DEFAULT_CHARSET. If a developper changes this setting, I believe it should apply to the HTTP side of the application as a whole, and specifically, to the entire URL. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
