1
votes

my SOAP web service responds with ISO-8859-1 if no charset was set in the http request header.

I tried the following:

  • set the following in jvm.options: -Dfile.encoding=UTF-8 -Duser.language=en -Duser.country=US -Dclient.encoding.override=UTF-8
  • set environment variable (global): DEFAULT_CLIENT_ENCODING=UTF-8
  • created a SOAP handler adding charset=UTF-8 if not existing in Content-Type

But still, in the Liberty logs I see that the incoming message has the following headers set:

Encoding: ISO-8859-1
Http-Method: POST
Content-Type: application/soap+xml;action="myWSmethod"

Our end users tend to send their requests without charset in the request header. We used to have traditional WAS8, that used UTF-8 as default. Setting Liberty to also use UTF-8 fails somehow.

Is there maybe a hidden option in the server.xml?

Liberty uses CXF and it is intercepting the incoming message and is setting this headers. Why is it still using ISO?

Kind regards

1

1 Answers

0
votes

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.