[Django] #24598: JsonResponse loses encoding support in Content-Type header
Django
-----------------------------------------+------------------------
Reporter: funkybob | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.8
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Needs documentation: 1 | Needs tests: 1
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
By default when a content_type is not passed to HttpResponse it will
create one from settings.DEFAULT_CONTENT_TYPE, and attach the encoding.
So, when unspecified, the header will appear as:
{{{
Content-Type: text/html; encoding=utf-8
}}}
However, if you specify the content_type, this action is no taken.
That's understandable in a "consenting adults" context, however the
JsonResponse sets content_type using kwargs.setdefault, thus forcing the
loss of encoding annotation in all responses.
I propose instead that HttpResponseBase check for a
``default_content_type`` property to override
settings.DEFAULT_CONTENT_TYPE, thus:
{{{
diff --git a/django/http/response.py b/django/http/response.py
index c8d6930..40186b5 100644
--- a/django/http/response.py
+++ b/django/http/response.py
@@ -54,8 +54,8 @@ class HttpResponseBase(six.Iterator):
self._reason_phrase = reason
self._charset = charset
if content_type is None:
- content_type = '%s; charset=%s' %
(settings.DEFAULT_CONTENT_TYPE,
- self.charset)
+ content_type = getattr(self, 'default_content_type',
settings.DEFAULT_CONTENT_TYPE)
+ content_type = '%s; charset=%s' % (content_type,
self.charset)
self['Content-Type'] = content_type
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24598>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: funkybob | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by funkybob):
Oops, forgot the second part of the patch:
{{{
@@ -470,11 +470,11 @@ class JsonResponse(HttpResponse):
:param safe: Controls if only ``dict`` objects may be serialized.
Defaults
to ``True``.
"""
+ default_content_type = 'application/json'
def __init__(self, data, encoder=DjangoJSONEncoder, safe=True,
**kwargs):
if safe and not isinstance(data, dict):
raise TypeError('In order to allow non-dict objects to be '
'serialized set the safe parameter to False')
- kwargs.setdefault('content_type', 'application/json')
data = json.dumps(data, cls=encoder)
super(JsonResponse, self).__init__(content=data, **kwargs)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24598#comment:1>
Django
Reporter: funkybob | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
Including a charset on `application/json` responses is invalid according
to #23949.
--
Ticket URL: <https://code.djangoproject.com/ticket/24598#comment:2>
Django
Reporter: funkybob | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by timgraham:
Old description:
New description:
By default when a content_type is not passed to `HttpResponse` it will
create one from `settings.DEFAULT_CONTENT_TYPE`, and attach the encoding.
So, when unspecified, the header will appear as:
{{{
Content-Type: text/html; encoding=utf-8
}}}
However, if you specify the `content_type`, this action is not taken.
That's understandable in a "consenting adults" context, however the
`JsonResponse` sets `content_type` using `kwargs.setdefault`, thus forcing
the loss of encoding annotation in all responses.
I propose instead that `HttpResponseBase` check for a
`default_content_type` property to override
`settings.DEFAULT_CONTENT_TYPE`, thus:
{{{
#!diff
diff --git a/django/http/response.py b/django/http/response.py
index c8d6930..40186b5 100644
--- a/django/http/response.py
+++ b/django/http/response.py
@@ -54,8 +54,8 @@ class HttpResponseBase(six.Iterator):
self._reason_phrase = reason
self._charset = charset
if content_type is None:
- content_type = '%s; charset=%s' %
(settings.DEFAULT_CONTENT_TYPE,
- self.charset)
+ content_type = getattr(self, 'default_content_type',
settings.DEFAULT_CONTENT_TYPE)
+ content_type = '%s; charset=%s' % (content_type,
self.charset)
self['Content-Type'] = content_type
}}}
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24598#comment:3>
Django
Reporter: funkybob | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by claudep):
Isn't this one a simple duplicate of #23949?
--
Ticket URL: <https://code.djangoproject.com/ticket/24598#comment:4>
Django
Reporter: funkybob | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I think so, but I thought I'd give Curtis an opportunity to say if there
are any other valid use cases this patch might enable.
--
Ticket URL: <https://code.djangoproject.com/ticket/24598#comment:5>
Django
Reporter: funkybob | Owner: nobody
Type: Bug | Status: closed
Component: HTTP handling | Version: 1.8
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by funkybob):
* status: new => closed
* resolution: => duplicate
Comment:
The reading is quite clear, so I guess the bug I was encountering which
inspired this must be further down the line -- possibly in requests.
--
Ticket URL: <https://code.djangoproject.com/ticket/24598#comment:6>