I think switching the encoding to iso-8859-1 won't solve the issue because that won't be right.
all headers are supposed to be encoded in US-ASCII. http://tools.ietf.org/html/rfc2822#page-7 Non ASCII values needed to be encoded using a special ASCII encoding http://tools.ietf.org/html/rfc2047 We typically assume all headers are already encoded in ASCII for the soap binding, so no special encoding is applied. BP-I doesn't talk about the valid soap action values, probably assuming the same thing. I never encountered a non-ascii SOAPAction and I don't know what exactly BizTalk is expecting (e.g., decoding using the local charset or expecting the encoding scheme of rfc2047). 2014-06-22 14:13 GMT+02:00 Younes Ouadi <[email protected]>: > The whole sample, after modification, is attached to this e-mail. > > Warm regards. > > Younes > > > > On Sun, Jun 22, 2014 at 1:12 PM, Younes Ouadi <[email protected]> > wrote: >> >> Hello Dears, >> >> I'm stuck with the Async Client and accented characters. Please help. >> >> As suggested by @Daniel, I have suitched to Async Client hoping to solve >> my initial issue, that is: consuming a web service whose SOAPAction contains >> an accented character. >> >> To do so: >> * I took the sample program that is distributed with CXF 2.7.11 >> (apache-cxf-2.7.11-src/distribution/src/main/release/samples/jaxws_async) >> * I have add two interceptors one for the server and one for the client >> (sorry, this is the first time I'm hooking into CXF and this is the only way >> I found to add arbitrary headers to CXF request). >> * When the header doesn't contain accented characters, every thing works >> well. The client initiate the request with the arbitrary header, the server >> receives the request along with the header, process it and sends back the >> response to the client. >> * When the header contains an accented character, the client fail to >> initiate the request with the error: >> "java.util.concurrent.ExecutionException: >> java.nio.charset.UnmappableCharacterException: Input length = 1" >> * Googling this error shows (in other context of course) that there is an >> issue with the encoding. >> * I tried to enforce the use of ISO-8859-1, but with no luck. >> >> The interceptor at the client side is as follows: >> public class ClientHttpHeaderInterceptor extends >> AbstractPhaseInterceptor<Message>{ >> >> public ClientHttpHeaderInterceptor() { >> super(Phase.PREPARE_SEND); >> } >> >> @Override >> public void handleMessage(Message message) throws Fault { >> // message.put(Message.CONTENT_TYPE, "text/xml; >> charset=ISO-8859-1"); >> // message.put(Message.ENCODING, "ISO-8859-1"); >> >> @SuppressWarnings("unchecked") >> Map<String, List<String>> headers = (Map<String, >> List<String>>)message.get(Message.PROTOCOL_HEADERS); >> if ( headers != null ) { >> List<String> header = new ArrayList<String>(); >> header.add("Héader"); >> >> System.out.println("========================= Adding My >> Header: " + header); >> >> headers.put("My Header", header); >> >> message.put(Message.PROTOCOL_HEADERS, headers); >> } >> } >> } >> >> >> The interceptor at the server side is as follows: >> public class ServerHttpHeaderInterceptor extends >> AbstractPhaseInterceptor<Message>{ >> >> public ServerHttpHeaderInterceptor() { >> super(Phase.PRE_INVOKE); >> } >> >> @Override >> public void handleMessage(Message message) throws Fault { >> @SuppressWarnings("unchecked") >> Map<String, List<String>> headers = (Map<String, >> List<String>>)message.get(Message.PROTOCOL_HEADERS); >> if ( headers != null ) { >> if ( headers.get("My Header") != null ) { >> System.out.println("========================= Received My >> Header: " + headers.get("My Header").toString()); >> } >> else { >> System.out.println("========================= Received My >> Header: none"); >> } >> } >> } >> } >> >> >> Warm regards >> >> Younes >> >> >> >> >> >> >> >> On Sat, Jun 21, 2014 at 10:08 AM, Younes Ouadi <[email protected]> >> wrote: >>> >>> Hi @Daniel, >>> >>> I appreciate very much your help. Thank you for the time, effort and >>> attention you have devoted to this question. >>> >>> For your recommendation, I can't do much. The WSDL in question is already >>> in production consumed by a BizTalk-base client (the server is also a >>> BizTalk based server, as you can see it in the WSDL). >>> >>> I will give a try to the Async Client and let you know the outcome. >>> >>> Warm regards >>> >>> Younes >>> >>> >>> >>> >>> >>> On Fri, Jun 20, 2014 at 5:29 PM, Daniel Kulp <[email protected]> wrote: >>>> >>>> >>>> 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 >>>> >>> >> >
