Opened 10 years ago

Closed 10 years ago

Last modified 8 years ago

#333 closed (fixed)

HttpResponse should get a default charset

Reported by: hugo <gb@…> Owned by: adrian
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: UI/UX:

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@…> 10 years ago.
splitting DEFAULT_MIME_TYPE into DEFAULT_CONTENT_TYPE and DEFAULT_CHARSET

Download all attachments as: .zip

Change History (12)

comment:1 Changed 10 years ago by adrian

  • Status changed from new to assigned

comment:2 Changed 10 years ago by anonymous

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 Changed 10 years ago by Maniac@…

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 Changed 10 years ago by hugo <gb@…>

  • priority changed from normal to high

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 Changed 10 years ago by adrian

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in [670].

comment:6 Changed 10 years ago by Maniac@…

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 Changed 10 years ago by adrian

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.

Changed 10 years ago by Maniac <Maniac@…>

splitting DEFAULT_MIME_TYPE into DEFAULT_CONTENT_TYPE and DEFAULT_CHARSET

comment:8 Changed 10 years ago by Maniac <Maniac@…>

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 Changed 10 years ago by adrian

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:10 Changed 10 years ago by adrian

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:11 Changed 9 years ago by Go

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