Not sure why you would have to set that manually, if the page already has the 
contentType attribute set in the page directive.

What I've noticed is that the JSPs that fail to render properly have only:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

in them with respect to content type and character encoding.  The files that DO 
render correctly, have the same:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

as well as:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>

in the source of the page.

In the case where the page has the <meta http=equiv tag, the response is 
received at mod_jk with the correct HTTP headers and the meta tag removed from 
the page (by JBoss/Tomcat?) and the page is rendered correctly.

In the case where the page only has the JSP page directive for contentType, 
there is no HTTP header for Content-Type seen (by mod_jk) and is, apparently, 
tagged with the default Content-Type when a header is not found -- text/plain 
-- presumably by Apache on the way out.

A) Why is the JSP directive not sufficient to generate the HTTP Content-Type 
header or who is dropping/ignoring/losing it?

B) Isn't including the meta http-equiv tag in addition to setting the content 
type in the JSP redundant?  

View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009053#4009053

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009053
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to