Opened 19 years ago

Closed 18 years ago

Last modified 17 years ago

#333 closed (fixed)

HttpResponse should get a default charset

Reported by: hugo <gb@…> Owned by: Adrian Holovaty
Component: Core (Other) Version:
Severity: normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The default charset for a HttpResponse should be utf-8 and should be sent out with the Content-type header. If users want to change that, they can override the charset, but by default Django just sends our text/html without a specified charset.

Attachments (1)

333.diff (7.4 KB ) - added by Maniac <Maniac@…> 18 years ago.
splitting DEFAULT_MIME_TYPE into DEFAULT_CONTENT_TYPE and DEFAULT_CHARSET

Download all attachments as: .zip

Change History (12)

comment:1 by Adrian Holovaty, 19 years ago

Status: newassigned

comment:2 by anonymous, 19 years ago

On django/utils/httpwrappers.py the DEFAULT_MIME_TYPE is just "text/html". That means the web browsers sometimes show "weird things" when one uses non-ascii characters on the templates (example: customize base_site.html adding some utf-8 characters and open the http://.../admin/ login page). It would be better to define a default charset, changing that to DEFAULT_MIME_TYPE = 'text/html; charset=utf-8' (the same mimetype used on the admin interface).

comment:3 by Maniac@…, 19 years ago

I made a patch for task 440 which fixes this task also. It creates a parameter 'DEFAULT_CHARSET' in project settings and uses it for output and input from forms. In absence of the parameter this setting defaults to 'utf-8' of course...

comment:4 by hugo <gb@…>, 19 years ago

priority: normalhigh

updated to high priority because this is really annoying - and with generic views even problematic, if you put forms in the templates for the generic views, because those won't provide the right charset and might fall back to iso-8859-1 and so break when non-ascii chars are entered.

comment:5 by Adrian Holovaty, 18 years ago

Resolution: fixed
Status: assignedclosed

Fixed in [670].

comment:6 by Maniac@…, 18 years ago

Adrian, some time ago I made a patch for ticket 440 introducing DEFAULT_CHARSET set to 'utf-8'. I made it that way to use the charset for decoding submitted text fields data. Now with integral DEFAULT_MIME_TYPE it's a bit less reliable (and a bit more ugly :-) ) to parse out this 'utf-8' thing.

I can rework this whole thing to break DEFAULT_MIME_TYPE into DEFAULT_CONTENT_TYPE and DEFAULT_CHARSET. Or I can just hardcode 'utf-8'. The latter is a sleeping bomb though... What do you like better?

comment:7 by Adrian Holovaty, 18 years ago

Hey Maniac -- Sorry for breaking that patch! Yes, splitting it into DEFAULT_MIME_TYPE and DEFAULT_CONTENT_TYPE would be excellent. Go right ahead, and I'll integrate it.

by Maniac <Maniac@…>, 18 years ago

Attachment: 333.diff added

splitting DEFAULT_MIME_TYPE into DEFAULT_CONTENT_TYPE and DEFAULT_CHARSET

comment:8 by Maniac <Maniac@…>, 18 years ago

Sorry for the delay, been busy with my django-powered project :-)

So attached patch splits mimetype into parts. I also replaced hard-coded 'utf-8' throughout the code with DEFAULT_CHARSET (except things related to feeds and rss that seem to me not related to this default).

This patch also fixes ticket 440.

comment:9 by Adrian Holovaty, 18 years ago

Resolution: fixed
Status: closedreopened

comment:10 by Adrian Holovaty, 18 years ago

Resolution: fixed
Status: reopenedclosed

(In [786]) Fixed #333 and #440 -- Split DEFAULT_MIME_TYPE setting into DEFAULT_CONTENT_TYPE and DEFAULT_CHARSET. Thanks, Maniac.

comment:11 by Go, 18 years ago

Type: defect
Note: See TracTickets for help on using tickets.
Back to Top