RE: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Could you please remove us from this email distribution list? Thanks. Final Draft Support -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Thursday, February 02, 2006 11:32 AM To: 'Tomcat Developers List' Subject: RE: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, February 02, 2006 4:02 AM To: Tomcat Developers List Subject: Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catali na/connector/Response.java Bill Barker wrote: Yes, RFC 2616 does specify iso-latin-1 as the default for HTTP/1.1 clients. However, section 3.4.1 is also relevant for HTTP/1.0 clients (like, say, the TCK :). In any case, it doesn't matter since section 5.4 of the servlet spec says must. Complaints go to the expert group; here we just develop Tomcat. Ok, so I asked the expert group, and many people interpret the specification as I do (and is logical to do): if the application uses a writer, and never specifies the charset in any way, the container has no business rewriting the content-type header to include ;charset=ISO-8859-1. Then they should make the language in the spec clearer ;-). If I'm misunderstanding the spec, then I don't have a valid reason for my veto. Consider the veto withdrawn. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Bill Barker wrote: Yes, RFC 2616 does specify iso-latin-1 as the default for HTTP/1.1 clients. However, section 3.4.1 is also relevant for HTTP/1.0 clients (like, say, the TCK :). In any case, it doesn't matter since section 5.4 of the servlet spec says must. Complaints go to the expert group; here we just develop Tomcat. Ok, so I asked the expert group, and many people interpret the specification as I do (and is logical to do): if the application uses a writer, and never specifies the charset in any way, the container has no business rewriting the content-type header to include ;charset=ISO-8859-1. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Bill Barker wrote On 02/02/06 11:32,: -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, February 02, 2006 4:02 AM To: Tomcat Developers List Subject: Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catali na/connector/Response.java Bill Barker wrote: Yes, RFC 2616 does specify iso-latin-1 as the default for HTTP/1.1 clients. However, section 3.4.1 is also relevant for HTTP/1.0 clients (like, say, the TCK :). In any case, it doesn't matter since section 5.4 of the servlet spec says must. Complaints go to the expert group; here we just develop Tomcat. Ok, so I asked the expert group, and many people interpret the specification as I do (and is logical to do): if the application uses a writer, and never specifies the charset in any way, the container has no business rewriting the content-type header to include ;charset=ISO-8859-1. Then they should make the language in the spec clearer ;-). If I'm misunderstanding the spec, then I don't have a valid reason for my veto. Consider the veto withdrawn. I don't think you are misunderstanding the spec. See the following javadocs snippets from ServletResponse: public String getCharacterEncoding(): * If no character encoding * has been specified, codeISO-8859-1/code is returned. public PrintWriter getWriter() throws IOException: * If the response's character encoding has not been * specified as described in codegetCharacterEncoding/code * (i.e., the method just returns the default value * codeISO-8859-1/code), codegetWriter/code * updates it to codeISO-8859-1/code. public void setCharacterEncoding(String charset): * pContainers *must* communicate the character encoding used for * the servlet response's writer to the client if the protocol * provides a way for doing so. In the case of HTTP, the character * encoding is communicated as part of the codeContent-Type/code * header for text media types. Jan Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 24, 2006 12:52 AM
To: Tomcat Developers List
Subject: Re: svn commit: r371765 -
/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catali
na/connector/Response.java
Bill Barker wrote:
Author: remm
Date: Mon Jan 23 17:13:19 2006
New Revision: 371765
URL: http://svn.apache.org/viewcvs?rev=371765view=rev
Log:
- Remove nonsensical systematic inclusion on ISO-8859-1
charset in the content type, which is noth
useless and inefficient.
-1
Sending the charset used by the Writer is very clearly
required by the
servlet spec.
Thanks, I expected no less coming from you :) I will revert my patch.
A couple questions for your enjoyment:
1) Is this relevant or irrelevant from the HTTP specification
perspective ?
It's relevant to the browser trying to display the code. If you've
configured your browser's default encoding to EUC-JP, without the charset
you'll see a big mess when you hit a latin-1 page ;-).
2) Does this mean we're running the following ultra efficient code (I
don't even know why I accepted this stuff back then. It must
have been
that this has been done gradually through many many commits) for each
request that uses a writer ?
Yup, that's what it means :). I'm sure you've played the blame-game by now,
and I'm not interested enough to do it myself. It looks like it's trying to
avoid computing the entire header value each time the characterEncoding
changes.
public String getContentType() {
String ret = contentType;
if (ret != null
characterEncoding != null
charsetSet) {
ret = ret + ;charset= + characterEncoding;
}
return ret;
}
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication
in error, please notify us immediately by e-mail and then delete all copies of
this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through
the Internet is not secure. Do not send confidential or sensitive information,
such as social security numbers, account numbers, personal identification
numbers and passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Bill Barker wrote: It's relevant to the browser trying to display the code. If you've configured your browser's default encoding to EUC-JP, without the charset you'll see a big mess when you hit a latin-1 page ;-). Obviously, this would only impact the case where ;charset=ISO-8859-1 would be forcefully added to the content-type header for no good reason when the user didn't specify any. This is the HTTP default encoding, and will not change the behavior from the user perspective. Yup, that's what it means :). I'm sure you've played the blame-game by now, and I'm not interested enough to do it myself. It looks like it's trying to avoid computing the entire header value each time the characterEncoding changes. This whole thing is a huge mess right now. Hopefully, it's doing what it should. You can also for example compare o.a.c.connector.Response.setContentType with o.a.coyote.Response.setContentType. I have to suppose substring and concatenation is a very cool activity. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: It's relevant to the browser trying to display the code. If you've configured your browser's default encoding to EUC-JP, without the charset you'll see a big mess when you hit a latin-1 page ;-). Obviously, this would only impact the case where ;charset=ISO-8859-1 would be forcefully added to the content-type header for no good reason when the user didn't specify any. This is the HTTP default encoding, and will not change the behavior from the user perspective. Yes, RFC 2616 does specify iso-latin-1 as the default for HTTP/1.1 clients. However, section 3.4.1 is also relevant for HTTP/1.0 clients (like, say, the TCK :). In any case, it doesn't matter since section 5.4 of the servlet spec says must. Complaints go to the expert group; here we just develop Tomcat. Yup, that's what it means :). I'm sure you've played the blame-game by now, and I'm not interested enough to do it myself. It looks like it's trying to avoid computing the entire header value each time the characterEncoding changes. This whole thing is a huge mess right now. Hopefully, it's doing what it should. You can also for example compare o.a.c.connector.Response.setContentType with o.a.coyote.Response.setContentType. I have to suppose substring and concatenation is a very cool activity. Yeah, the spec is a mess wrt characterEncoding. Complaints to the same place as above :). The problem is that we need to deal with such pathological cases as: response.setContentType(text/html; charset=EUC-JP); // Oops, I want French instead of Japanese response.setCharacterEncoding(iso-8859-1); Since you can change your mind (according to the spec) many times before you actually grab the Writer, I don't really see a way around substring and concatenation being cool :). Of course, I would love to be proven wrong :). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 5:13 PM To: tomcat-dev@jakarta.apache.org Subject: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catali na/connector/Response.java Author: remm Date: Mon Jan 23 17:13:19 2006 New Revision: 371765 URL: http://svn.apache.org/viewcvs?rev=371765view=rev Log: - Remove nonsensical systematic inclusion on ISO-8859-1 charset in the content type, which is noth useless and inefficient. -1 Sending the charset used by the Writer is very clearly required by the servlet spec. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
