Looking at the code for the JDK: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/net/NetworkClient.java#NetworkClient.0encoding
I see they intentionally leave it in whatever encoding it find with the “file.encoding” system property at startup providing all the ASCII characters work. Kind of wrong if you ask me, but that does mean that you really can only rely on the ASCII level character being transferred properly. Dan On Jun 20, 2014, at 12:06 PM, Daniel Kulp <[email protected]> wrote: > > Some bad news…. with a little bit of good news. > > The HttpURLConnection that CXF uses by default for sending requests to the > server always seems to use UTF-8. I checked with Java 6/7/8 and they all do > that. There doesn’t seem to be any way to make it behave correctly. :-( > If you can try creating an HttpURLConnection and calling > setRequestProperty(“SOAPAction”, “Héader”) or something and doing a wireshark > or similar, you’ll see it’s sending as UTF-8 encoded. Seems to be a bug in > the JDK. If you can figure out away to get it to properly send the header, > I’d love to see it. > > Both of the async clients we have (Netty on 3.0 and the Async client on both > 2.7 and 3.0) seem to handle ISO-8859-1 headers properly. Thus, you can add > the appropriate dependencies and configure it to “aways” use the async > transport and it should transfer fine. > > HOWEVER - neither of those will handle any characters outside of 8859-1. > They don’t encode the header using the RFC that’s there for encoding headers > outside of the 8859-1 code set. Thus, this still isn’t a full solution. > > That all said, I’d STRONGLY STRONGLY encourage you to change the Action to > NOT have those characters. Any client that uses the JAX-WS reference > implementation built into the JDK would also fail (due to them also using the > HttpURLConnection). > > > Dan > > > On Jun 20, 2014, at 4:42 AM, Younes Ouadi <[email protected]> wrote: > >> Hello Dears, >> >> I have an issue with soap-actions that contains accented charaters. I'm >> sure that this is not something new and it is possible that I'm missing >> something. So, please help. >> >> My case is as follows: >> * I have received a WSDL of a third party system >> * I have used wsdl2java maven plugin to generate classes >> * I have setted up a client and a server using Spring method >> * When I try to consume a service, the server reject my request with: 'The >> given SOAPAction does not match an operation' >> * The logs shows that the SOAPAction header: >> ** at the client side contains the corrcet value which contain an accented >> character (the character 'é') >> ** at the server side, it contains a wrong value (the 'é' is replace by two >> other charaters) >> >> It looks like that CXF: >> * at the client side, it hase encoded the the header value using UTF-8 >> * while at the the server side, it has decoded the header value using >> ISO-8859-1 >> >> I have asked this question on SO and I have got a reply saying that as per >> HTTP Specs, headers should be in ISO-8859-1. >> >> My question here is: how I can ask CXF to encode headers, at the client >> side, using ISO-8859-1 instead of UTF-8? >> >> My config is: >> * OS: Fedora 19 >> * JDK: Java(TM) SE Runtime Environment (build 1.6.0_33-b03) | Java >> HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) >> * CXF: 2.7.11 >> >> I have put all the detail of thsi case on SO. Please see ' >> http://stackoverflow.com/questions/24305749/cxf-jaxws-endpoint-fail-with-the-given-soapaction-does-not-match-an-operation >> '. >> >> Warm regards. >> >> Younes Ouadi > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
