Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#29511 closed Bug (fixed)

Set the charset on the JavaScriptCatalog response

Reported by: Roland van Laar Owned by: nobody
Component: Internationalization Version: 1.11
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

What I want: set the charset on responses with javascript files.

The supposed way of doing that is setting the DEFAULT_CHARSET in settings.py.
However, this setting isn't used when the content_type is specified when calling HttpResponse.

It seems to me that this is a bug. Why accept charset as an option when it only does something
when content_type is set.

django.views.i18n.JavascriptCatalog sets this text/javascript as the content_type.
Whereas it should be: text/javascript; charset=utf-8.

Change History (12)

comment:1 by Tim Graham, 7 years ago

Component: Generic views → Internationalization
Summary: Set the chartset on JavaScript catalog in Django Views i18n → Set the charset on the JavaScriptCatalog response

Are you experiencing a problem due to the lack of charset=utf-8?

Last edited 7 years ago by Tim Graham (previous) (diff)

comment:2 by Roland van Laar, 7 years ago

I am not experiencing problems directly. However it was 'strongly advised' after a security audit of our application.

I was expecting it to be configurable, or to be able to inject. The way the HttpResponse works is by not setting the charset when content_type is specified.
That seems like a bug as well.

comment:3 by Claude Paroz, 7 years ago

I think adding the charset for JavaScriptCatalog makes sense.

HttpResponse consider that if the content_type is already set, it's the responsability of the setter to set the charset if needed. I wouldn't change that.

comment:4 by Tim Graham, 7 years ago

Has patch: set

​PR

comment:5 by Tim Graham, 7 years ago

Triage Stage: Unreviewed → Accepted

comment:6 by Roland van Laar, 7 years ago

Thank you Tim, for picking this up so quickly.

comment:7 by Claude Paroz, 7 years ago

Triage Stage: Accepted → Ready for checkin

comment:8 by Carlton Gibson <carlton.gibson@…>, 7 years ago

Resolution: → fixed
Status: new → closed

In 7cdeb23:

Fixed #29511 -- Added charset to JavaScriptCatalog's Content-Type header.

comment:9 by Carlton Gibson <carlton.gibson@…>, 7 years ago

In 714612a6:

[2.1.x] Fixed #29511 -- Added charset to JavaScriptCatalog's Content-Type header.

Backport of 7cdeb23ae7ef2d125276840ff298dbb9683959f2 from master

comment:10 by Carlton Gibson <carlton.gibson@…>, 7 years ago

In 8e082a6:

[2.0.x] Fixed #29511 -- Added charset to JavaScriptCatalog's Content-Type header.

Backport of 7cdeb23ae7ef2d125276840ff298dbb9683959f2 from master

comment:11 by Tim Graham, 7 years ago

How doe the fix qualify for a backport? If it does, it should have a 2.0.x release note.

comment:12 by Tim Graham <timograham@…>, 7 years ago

In 4b3b9fab:

[2.0.x] Reverted "Fixed #29511 -- Added charset to JavaScriptCatalog's Content-Type header."

This reverts commit 8e082a6e0b63a1cfdb0bc7b2835c6447123aa239 as it
doesn't qualify for a backport.

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