> Also note that Struts' multipart processing currently is rather clumsy > in handling form encoding. If the request object returns null from > "getCharacterEncoding()", then Struts assumes ISO-8859-1. I was
Isn't it Tomcat itself? This is a behaviour per servlets specifications (see page 41 of 2.4 specs).
There's a specific chunk of code in CommonsMultipartRequestHandler which has "ISO-8859-1" hard-coded as the fallback encoding if request.getCharacterEncoding() returns null. I brought this up on one of the struts lists when I encountered it a few months ago, but didn't feel satisfied of a correct way to expose the value as a configuration parameter. My concern was making it clear that setting it would only impact the request handler, because any configuration name I could think of might lead people to believe that Struts was also taking responsibility for calling request.setCharacterEncoding(...).
In the last couple of days, we've been talking a bit about possible changes to Struts configuration, and I think Martin has some pretty big plans for file upload handling in Struts 1.3, and this hasn't been a big issue for many people, so we'll probably let it float a while longer still.
> setting the request encoding with a custom command in a chain-requestprocessor, but the request was still returning a null value in> CommonsMultipartRequestHandler where the non-uploaded fields werebeing processed. Of course, this may have nothing to do with your situation.
As far as I know, this is a behaviour per specifications. Page 41 and 198 of servlets 2.4 specs: changing the character encoding must be done prior to reading request parameters or reading input. Odds are high there is something which reads input before you set the request encoding.
yes, you're probably right. Next time I turn to the issue, I'll use a servlet filter.
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
