[Zope3-Users] Re: why does HTTPResponse insist on a text mime type for unicode?

[Stefan Rank]

on 29.06.2006 20:58 Philipp von Weitershausen said the following:
> Stefan Rank wrote:
>> I am trying to make my content object IExternallyEditable, and I ran up
>> against the following code in
>> zope.publisher.http.HTTPResult._implicitResult (line 849ff)::
>>
>>     if isinstance(body, unicode):
>>         try:
>>             if not content_type.startswith('text/'):
>>                 raise ValueError(
>>                     'Unicode results must have a text content type,'
>>                     'got %s.' % content_type)
>>         except AttributeError:
>>                 raise ValueError(
>>                     'Unicode results must have a text content type.')
>>
>> (note: the first raise originally did not give the feedback about the
>> received content type.)
>>
>> And my question is: Why? (do unicode results need to have a text/* type)
> 
> Unicode can't be sent over the wire. Hence the publisher will have to
> encode it with a proper encoding (e.g. UTF-8) before transmitting the
> data.

yes.
I thought I could reuse the encoding selection logic already present in 
_implicitResult (see the paragraph you snipped).
But, as you write at the end,

>> The reason AFAICT is that my content object just stores its source as
>> unicode object and simply provides that in its IReadFile adapter.
> 
> IReadFile should really return byte strings, not unicode.

when used directly via the FTP publisher, using e.g. utf-8 is needed anyway.
Thanks.

About charset and http:

> When doing so, it will have to set the charset in the response.
> AFAIK only text/* responses are supposed to have a charset parameter,
> because everything else is just byte strings.

I tried to verify that: section 3.7.1 "Canonicalization and Text 
Defaults" of rfc2068 (HTTP/1.1) is not really clear. The fourth 
paragraph reads to me as if all media types might use explicit charset 
if they want.
but nevermind.

cheers,
stefan