Return-Path: 
 <issues-return-27525-apmail-cxf-issues-archive=cxf.apache.org@cxf.apache.org>
X-Original-To: apmail-cxf-issues-archive@www.apache.org
Delivered-To: apmail-cxf-issues-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 0ACA110EB5
	for <apmail-cxf-issues-archive@www.apache.org>;
 Wed, 23 Oct 2013 02:21:43 +0000 (UTC)
Received: (qmail 65268 invoked by uid 500); 23 Oct 2013 02:21:42 -0000
Delivered-To: apmail-cxf-issues-archive@cxf.apache.org
Received: (qmail 65227 invoked by uid 500); 23 Oct 2013 02:21:42 -0000
Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@cxf.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@cxf.apache.org>
List-Post: <mailto:issues@cxf.apache.org>
List-Id: <issues.cxf.apache.org>
Reply-To: dev@cxf.apache.org
Delivered-To: mailing list issues@cxf.apache.org
Received: (qmail 65059 invoked by uid 99); 23 Oct 2013 02:21:42 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Oct 2013 02:21:42 +0000
Date: Wed, 23 Oct 2013 02:21:42 +0000 (UTC)
From: "Jesse Pangburn (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12675175.1382494887772.107934.1382494902449@arcas>
In-Reply-To: <JIRA.12675175.1382494887772@arcas>
References: <JIRA.12675175.1382494887772@arcas>
Subject: [jira] [Created] (CXF-5354) faultTo address is ignored when fault
 is thrown
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394

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)