Re: change to contract of ServletRequest.setCharacterEncoding()

From: Ed Burns <>
Date: Thu, 18 Aug 2005 13:14:02 -0700

>>>>> On Thu, 18 Aug 2005 12:37:34 -0700, Ed Burns <> said:

>>>>> On Thu, 18 Aug 2005 12:18:20 -0700, Jan Luehe <Jan.Luehe_at_Sun.COM> said:
JL> From the stack trace you sent, it looks like


JL> is parsing req params from the POST body and then request dispatching
JL> to


JL> which then calls setCharacterEncoding(), which causes the ISE,
JL> because some req params have already been parsed.

JL> What we could do is have setCharacterEncoding() throw the ISE only
JL> if (getReader() has been called || req params have been read)
JL> AND the newly supplied encoding is different from the encoding
JL> that was used to parse the body.

JL> I can propose this to the EG. What do you think?

EB> I don't think that'll work. Let's say a webapp wants to use UTF-8 for
EB> everything. So, they use JSP directives to set a content type

EB> Content-Type: text/html; charset=UTF-8

EB> Now, when the browser submits the form, it'll convey any character
EB> encoding that it is configured to, regardless which encoding was used in
EB> the page from which the submit is originating. In JSF, we need to
EB> ensure that UTF-8 is set as the character encoding, so in this case, the
EB> encoding will be different and we'll still get the ISE.

I really think we should revert to the Servlet 2.4 behavior here and
make this be a no-op if the request params have been accessed or a
reader has been obtained.

If you must have a case in which an ISE is thrown, limit it to only if
getReader() was called.


|  | {home: 407 869 9587, office: 408 884 9519 OR x31640}
| homepage:         |
| aim: edburns0sunw | iim: