Opened 2 years ago

Closed 2 years ago

Last modified 2 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 Changed 2 years ago by Tim Graham

Component: Generic viewsInternationalization
Summary: Set the chartset on JavaScript catalog in Django Views i18nSet the charset on the JavaScriptCatalog response

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

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

comment:2 Changed 2 years ago by Roland van Laar

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 Changed 2 years ago by Claude Paroz

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 Changed 2 years ago by Tim Graham

Has patch: set

comment:5 Changed 2 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

comment:6 Changed 2 years ago by Roland van Laar

Thank you Tim, for picking this up so quickly.

comment:7 Changed 2 years ago by Claude Paroz

Triage Stage: AcceptedReady for checkin

comment:8 Changed 2 years ago by Carlton Gibson <carlton.gibson@…>

Resolution: fixed
Status: newclosed

In 7cdeb23:

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

comment:9 Changed 2 years ago by Carlton Gibson <carlton.gibson@…>

In 714612a6:

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

Backport of 7cdeb23ae7ef2d125276840ff298dbb9683959f2 from master

comment:10 Changed 2 years ago by Carlton Gibson <carlton.gibson@…>

In 8e082a6:

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

Backport of 7cdeb23ae7ef2d125276840ff298dbb9683959f2 from master

comment:11 Changed 2 years ago by Tim Graham

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

comment:12 Changed 2 years ago by Tim Graham <timograham@…>

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