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
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
