DO NOT REPLY [Bug 36790] - response.setContentType() never forgets charset
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36790. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36790 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-25 10:10 --- For crying out loud, you quoted the part of the spec that requires this behaviour in comment #2. Please, just read the spec. spec-quote section=SRV.5.2 The setCharacterEncoding, setContentType, and setLocale methods can be called repeatedly to change the character encoding ... Calls to setContentType set the character encoding only if the given content type string provides a value for the charset attribute. /sepc-quote Therefore, response.setContentType(text/html; charset=utf-8); sets the character encoding and response.setContentType(application/x-foobar); does not change it. This is not a bug. If you re-open this bug again, it is just going to be closed again with no further comment. If you have further questions about this, then please ask them on the tomcat-user mailing list although to be perfectly frank you could save yourself some time by reading the spec. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36790] - response.setContentType() never forgets charset
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36790.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36790
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Additional Comments From [EMAIL PROTECTED] 2005-09-24 19:17 ---
I understand the character encoding defaults to ISO-8859-1, but I guess it boils
down to for the following servlet code, shouldn't the Content-Type be
application/x-foobar? Tomcat 5.0.28 is sending
application/x-foobar;charset=utf-8.
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, java.io.IOException {
response.setContentType(text/html; charset=utf-8);
response.setContentType(application/x-foobar);
response.getOutputStream().println(new
java.util.Date().toString());
response.getOutputStream().close();
}
The spec doesn't seem clear on what happens when setContentType() is called a
second time without a charset, but it does seem clear that charset should only
get added for text/* MIME types.
Is the standard clear on whether charset should be sent if the servlet does
this?
response.setContentType(text/html; charset=utf-8);
response.setContentType(text/html);
Should the response default back to ISO-8859-1, and should the Content-Type have
;charset=ISO-8859-1 appended?
SRV.5.4 Internationalization
...
The setCharacterEncoding, setContentType, and
setLocale methods can be called repeatedly to change the character encoding.
Calls made after the servlet responses getWriter method has been called or
after
the response is committed have no effect on the character encoding. Calls to
setContentType set the character encoding only if the given content type string
provides a value for the charset attribute.
...
In the case of HTTP, the locale is communicated via the Content-
Language header, the character encoding as part of the Content-Type header for
text media types.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36790] - response.setContentType() never forgets charset
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36790. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36790 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-24 21:08 --- The spec is very clear that if you are using response.getWriter (e.g. you are using a JSP page), then you get a charset on your content type. Since you've already quoted the section, I won't bother to quote it again :). You have already pointed to the solution to your problem in your bullet 3) above: Don't use JSP pages for binary content. You can try TC 5.5, which has as much support as Tomcat will ever have for your misuse of JSP pages. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36790] - response.setContentType() never forgets charset
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36790.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36790
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Additional Comments From [EMAIL PROTECTED] 2005-09-25 05:54 ---
(In reply to comment #3)
The spec is very clear that if you are using response.getWriter (e.g. you are
using a JSP page), then you get a charset on your content type.
Okay, let's ignore JSP's for now. Should this servlet respond with
Content-Type: application/x-foobar;charset=UTF-8
It does on Tomcat 5.0.28 and 5.5, but I don't think it should be
appending charset.
The spec says charset should only be appended for text media content types.
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;
public class HelloWorldServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, java.io.IOException {
response.setContentType(text/html; charset=utf-8);
response.setContentType(application/x-foobar);
response.getOutputStream().println(new java.util.Date().toString());
response.getOutputStream().close();
}
}
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36790] - response.setContentType() never forgets charset
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36790. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36790 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-23 23:59 --- This behaviour is as per the JSP spec. spec-quote section=JSP.4.2 For JSP pages in standard syntax, it is the character encoding specified by the pageEncoding attribute of the page directive or by a JSP configuration element page-encoding whose URL pattern matches the page. ... If theres no such specification, no initial response character encoding is passed to ServletResponse.setContentType() - the ServletResponse objects default, ISO-8859-1, isused. /spec-quote -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
