#13391: Detect charset from Content-type header in the HttpResponse
------------------------------------+---------------------------------------
Reporter: lucky | Owner: nobody
Status: new | Milestone:
Component: HTTP handling | Version: SVN
Resolution: | Keywords: HttpResponse
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
------------------------------------+---------------------------------------
Comment (by lucky):
I tried to make the bug fix patch does not impose new responsibilities on
the HttpResponse object.
It just makes it possible to remove Django's uncertainty regarding to the
{{{_charset}}} in the most natural way for application - by providing
{{{charset}}} in the {{{content_type}}} argument or in the {{{Content-
type}}} header of the {{{http response}}}. I believe it is not violate
current behavior and spirit of the current implementation of the
HttpResponse.
In an ideal world
I personally believe that HttpResponse should work at the level of the
'headers' and the 'content' only. I was surprised that object has a own
{{{._charset}}} property at all. Charset is an property of the content
(and only of the special case of it "text content"). Therefore, the
functions to work with content's charset in the HttpResponse are
redundant. So I do not agree with current direction of HttpResponse
implementation where content-specific operations are implemented in it,
and #10190 too.
The guessing of the charset of the text content in the response, by
analyzing of the information from HttpRequest, or by from the projects
settings (settings.DEFAULT_CHARSET), or by ... are magic tasks for higher
level. That is some sort of the Middleware. Not for HttpResponse itself.
In the case of
[http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.4.1 Missing
Charset] it is better to move the charset guessing logic (and other
content-specific operations) out of HttpResponse, to the application
/client-level:
{{{
def guess_text_content_from_response(response,
default_charset=settings.DEFAULT_CHARSET):
"""
:rtype: string representation of the response content with valid
encoding.
"""
if response.has_key['Content-type'] ...
if getattr(response.content, 'encoding', None): ... # is content a
file?
if any other magic ...
return smart_str(response.content, guessed_charset)
def convert_response_to_be_accepted_for_request(response, request):
"""Converts response content with respect to ACCEPT_CHARSET header of
the ``request`` and adjust Content-type header.
if request.META.has_key("ACCEPT_CHARSET"):..
...
}}}
Properties of the content are describes in the
[http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17 Content-
type] header. The
[http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11 Content-
Encoding] header is about "transfer" encoding (it is not about content
charset). There are independent.
--
Ticket URL: <http://code.djangoproject.com/ticket/13391#comment:3>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
