如果未在http请求标头中设置任何字符集,我的SOAP Web服务将以 ISO-8859-1 进行响应。
我尝试了以下操作:
但仍然,在Liberty日志中,我看到传入消息设置了以下标头:
Encoding: ISO-8859-1
Http-Method: POST
Content-Type: application/soap+xml;action="myWSmethod"
我们的最终用户倾向于在请求标头中发送不带字符集的请求。我们曾经有传统的WAS8,默认使用UTF-8。 将Liberty设置为也使用UTF-8失败。
server.xml中是否存在隐藏选项?
Liberty使用CXF,它正在拦截传入的消息并设置此标头。为什么仍然使用ISO?
亲切的问候
答案 0 :(得分:0)
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.