[OGo-Bugs][Bug 1868] detecting charset information in headers
bugs@opengroupware.org
bugs@opengroupware.org
Fri, 4 May 2007 00:02:03 +0200 (CEST)
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.
http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1868
helge.hess@opengroupware.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
BugsThisDependsOn| |1848, 1852
------- Additional Comments From wsourdeau@inverse.ca 2007-05-03 23:44 -------
Created an attachment (id=525)
--> (http://bugzilla.opengroupware.org/bugzilla/attachment.cgi?id=525&action=view)
patch
------- Additional Comments From helge.hess@opengroupware.org 2007-05-04 00:01 -------
The encoding is supposed to be added by the HTTP renderer based on the encoding of the WOMessage.
In other words, the client is not supposed to set charset parameters in content-type headers (because
thats already tracked by the WOMessage encoding).
I don't see the gain, if the calling code can specify the charset in the header, it could also just call
setEncoding: on the WOMessage?
This:
"With the current code, configurations enabling WOMessageUseUTF8 won't interpret
iso messages correctly"
doesn't make any sense to me. If you want to deliver Latin-1, you just tell the WOMessage ([response
setContentEncoding: NSLatin1StringEncoding]).
Further I don't see how any of this relates to WOMessageUseUTF8. This default only sets the initial
encoding of the WOMessage after construction.
Finally, the really correct approach would be to configure the WOResponse charset based on the 'accept'
header of the WORequest.
Summary: It would be nice if you could explain why this patch is necessary when we already have the -
setContentEncoding: message to configure the encoding.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.