[
https://issues.apache.org/jira/browse/CXF-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803572#comment-13803572
]
Jesse Pangburn edited comment on CXF-5354 at 10/23/13 11:58 PM:
----------------------------------------------------------------
See attachment for a modification of the 2.7.6 jaxws_dispatch_provider sample
(first noticed the problem on my 2.7.7 installation, so used an older 2.7.6
installation to make sure it wasn't a problem specific to 2.7.7) to illustrate
the problem. To run it, open a terminal and execute:
mvn -P server
Then open another terminal and execute:
mvn -P client
The client requests a replyTo at one URL and a faultTo at another. There's
nothing actually listening on these URLs but they are on the same port (9000)
that the server is listening on, so in the server output you see:
org.apache.cxf.transport.http.HTTPException: HTTP response '404: Not Found'
when communicating with http://localhost:9000/replyBack
This is where it's trying to send the fault- to the replyTo address instead of
the faultTo address.
was (Author: jpangburn):
This is a modification of the 2.7.6 jaxws_dispatch_provider sample (first
noticed the problem on my 2.7.7 installation, so used an older 2.7.6
installation to make sure it wasn't a problem specific to 2.7.7) to illustrate
the problem. To run it, open a terminal and execute:
mvn -P server
Then open another terminal and execute:
mvn -P client
The client requests a replyTo at one URL and a faultTo at another. There's
nothing actually listening on these URLs but they are on the same port (9000)
that the server is listening on, so in the server output you see:
org.apache.cxf.transport.http.HTTPException: HTTP response '404: Not Found'
when communicating with http://localhost:9000/replyBack
This is where it's trying to send the fault- to the replyTo address instead of
the faultTo address.
> faultTo address is ignored when fault is thrown
> -----------------------------------------------
>
> Key: CXF-5354
> URL: https://issues.apache.org/jira/browse/CXF-5354
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.7.7
> Reporter: Jesse Pangburn
> Attachments: jaxws_dispatch_provider_test_faultto.zip
>
>
> I have a Provider based service and find that with WS-Addressing enabled, it
> doesn't handle FaultTo addresses properly. The case I found that caused this
> is when I turned on Schema Validation and sent a request that doesn't match
> the schema, then it throws a fault but instead sends the reply to the replyTo
> address. I then tried using a bogus mustUnderstand header to cause a fault
> to see if it was just related to the schema validation, but it has the same
> problem.
> Here's a sample request message to cause this (using mustUnderstand header so
> you don't have to setup schema validation to test):
> {code:xml}
> <?xml version="1.0"?>
> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope";>
> <soap:Header>
> <Action xmlns="http://www.w3.org/2005/08/addressing";>anything</Action>
> <MessageID
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9</MessageID>
> <To
> xmlns="http://www.w3.org/2005/08/addressing";>http://localhost:9003/xdsregistryb</To>
> <ReplyTo xmlns="http://www.w3.org/2005/08/addressing";>
> <Address>http://localhost:9003/replyBack</Address>
> </ReplyTo>
> <FaultTo xmlns="http://www.w3.org/2005/08/addressing";>
> <Address>http://localhost:9003/faultBack</Address>
> </FaultTo>
> <bogus soap:mustUnderstand="true">this junk will fault</bogus>
> </soap:Header>
> <soap:Body>
> <junk/>
> </soap:Body>
> </soap:Envelope>
> {code}
> Note the ReplyTo is http://localhost:9003/replyBack and the FaultTo is
> http://localhost:9003/faultBack. When I send to my Provider service, the log
> file shows the response going to the replyBack url, but the To address in
> WS-Addressing header shows the faultBack url- so it's halfway right! This is
> the case with both schema validation faults and the above example of bogus
> mustUnderstand header.
> Here's the Wireshark network trace (so there is no possibility of bad logging
> being the issue):
> {quote}
> POST /replyBack HTTP/1.1
> Content-Type: application/soap+xml; charset=UTF-8
> Accept: */*
> User-Agent: Apache CXF 2.7.7
> Cache-Control: no-cache
> Pragma: no-cache
> Host: localhost:9003
> Connection: keep-alive
> Content-Length: 706
> <soap:Envelope
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope";><soap:Header><Action
> xmlns="http://www.w3.org/2005/08/addressing"/><MessageID
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:6a5190fc-256f-428c-9e5e-8b79520bbf0c</MessageID><To
>
> xmlns="http://www.w3.org/2005/08/addressing";>http://localhost:9003/faultBack</To><RelatesTo
>
> xmlns="http://www.w3.org/2005/08/addressing";>urn:uuid:2eae8433-d42a-4749-b053-f5b5805fe8e9</RelatesTo></soap:Header><soap:Body><soap:Fault><soap:Code><soap:Value>soap:MustUnderstand</soap:Value></soap:Code><soap:Reason><soap:Text
> xml:lang="en">MustUnderstand headers: [bogus] are not
> understood.</soap:Text></soap:Reason></soap:Fault></soap:Body></soap:Envelope>
> {quote}
> Sorry, wiki markup is making bogus in red, not intentional. See how the
> address listed at the top doesn't match the WS-Addressing To address? With
> anonymous replyTo address then you get the fault back on the same synchronous
> request channel, and it still shows the /faultBack url in the To address.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
