Jesse Pangburn created CXF-5354:
-----------------------------------
Summary: 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
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)
