Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: 17 Feb 2004 08:43:58 -0000
Message-ID: <20040217084358.23966.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: dev@cocoon.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 26997] New:  -
    Encoding in HTTP-Header is not set by Serializer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26997>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26997

Encoding in HTTP-Header is not set by Serializer

           Summary: Encoding in HTTP-Header is not set by Serializer
           Product: Cocoon 2
           Version: 2.1.3
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: core
        AssignedTo: dev@cocoon.apache.org
        ReportedBy: sburkard@previon.ch


The Cocoon Serializer does not set the encoding in the HTTP-Header, it just sets
the mime-type in the header. additionally, it writes a meta-tag with mime-type
and encoding in the html. 
if now any component (for example apache webserver) sets a (wrong) default
encoding in the header, most browsers use this header-encoding and ignore the
meta-tag-encoding. 

--------------------------------------

here is an answer from jan uyttenhove from the cocoon-users-group to my question
regarding this issue. i think this could help the developer:

ATM, Cocoon set the meta content-type tag with the mime-type and the encoding of
the serializer. Furthermore, response.setContentType *is* called, which is one
of the ways to set the http encoding header. But it is called with argument
mime-type only, e.g. response.setContentType("text/html"), and we should be able
to do response.setContentType("text/html; charset=utf-8").
We should be able to set the full content-type (with charset) in HttpEnvironment
or in AbstractProcessingPipeline. I guess that involves changing at least the
setSerializer(...) in AbstractProcessingPipeline and passing the encoding.