I will not explain all your parameters, and you must understand that some you use are for client encoding, which is the request you got and not what you repond with...
Any way... to clarify about the 8859-1, the HTTP/1.1 rfc says:
The "charset" parameter is used with some media types to define the
character set (section 3.4) of the data. When no explicit charset
parameter is provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of "ISO-8859-1" when
received via HTTP. Data in character sets other than "ISO-8859-1" or
its subsets MUST be labeled with an appropriate charset value.
Some HTTP/1.0 software has interpreted a Content-Type header
without charset parameter incorrectly to mean "recipient should
guess." Senders wishing to defeat this behavior MAY include a
charset parameter even when the charset is ISO-8859-1 and SHOULD do
so when it is known that it will not confuse the recipient.
And how the application server handles the encoding...
The default behavior for WebSphere Application Server is, first, to
check if charset is set on content type header. If it is, then the
product uses content type header for character encoding; if it is not,
then the product uses character encoding set on server using the
system property default.client.encoding. If charset is not present and
the system property is not set, then the product uses ISO-8859-1.
Enabling autoRequestEncoding on a Web module changes the default
behavior: if charset it not present on an incoming request header, the
product checks the Accept-Language header of the incoming request and
does encoding using the first language found in that header. If there
is no charset on content type header and no Accept language header,
then the product uses character encoding set on server using the
system property default.client.encoding. As with the default behavior,
if charset is not present and the system property is not set, then the
product uses ISO-8859-1.