Tim,

On 5/25/21 11:22, Scott,Tim wrote:
Hi Chris,

"nah, nobody still uses Struts 1.x".
I wouldn't put it past this 14 year old application ...

:)

Mine is coming up on 20 years old.

But at this point, if you have things working, you can probably
stop.
>
My OCD says Nooooo!, but my pragmatic side says "leave it until I
have to change"

But something is *definitely* wrong if changing the default file
encoding causes your files to be corrupted. It is *extraordinarily*
unlikely that Tomcat or Struts is doing this. It is much more
likely to be your application somewhere writing to a Writer instead
of a Stream.

Whilst I haven't explored every class in detail, the classes I have
been working with are the first (of my code) to receive the requests
and the data I'm getting is already corrupted. For example, there's
nothing in my application code which writes to a temporary file as
part of this process. My code writes the data to an Oracle database,
binding as a binary (RAW) value.

The code you posted shows imports and then your interaction with the fileupload library. Do you know what else happens before this line of code?

ServletRequestContext requestContext = new ServletRequestContext(/* HttpServletRequest */ request);

If the application calls one of a series of methods on HttpServletRequest, it can cause a few things to happen:

1. A "reader" is obtained from the request, which will convert bytes -> chars.

2. The "reader" needs to know what character encoding to use. There are some rules to determine what encoding that is, but Tomcat itself will always fall-back to ISO-8859-1 (per HTTP spec) and that is the encoding which does not cause corruption for you.

Can you reproduce this in a testing environment? I'll bet we can write a Filter or Valve which can catch this bug red-handed.

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to