ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike M. (JIRA)" <>
Subject [jira] [Commented] (WSS-644) Error when a SOAP-Fault is thrown with MTOM enabled
Date Fri, 15 Feb 2019 06:58:00 GMT


Mike M. commented on WSS-644:

I'd be glad to test your fix. Is there a maven repository I can grab a SNAPSHOT from? It looks
like [this apache repository|]
doesn't hold wss4j nightlies (the snapshots in it aren't fresh)?

> Error when a SOAP-Fault is thrown with MTOM enabled
> ---------------------------------------------------
>                 Key: WSS-644
>                 URL:
>             Project: WSS4J
>          Issue Type: Bug
>    Affects Versions: 2.2.2
>         Environment: Tested with CXF 3.3.0 / WSS4J 2.2.2 on Oracle Java 8.
>            Reporter: Mike M.
>            Assignee: Colm O hEigeartaigh
>            Priority: Major
>             Fix For: 2.2.3, 2.3.0
> We think we may have found an issue that looks very similar to [this Camel one|]:
We use CXF/WSS4J for JAX-WS with JAXB in contract-first mode. We use WebService Security (signature
& encryption) and have MTOM serialization enabled per policy using:
> {code:xml}
>     <wsoma:OptimizedMimeSerialization />
> {code}
> Everything seems to work fine when normal responses are generated from our Server. However,
when a SOAP-Fault occurs, the CXF client throws a parsing exception like this one (it says:
"Prefix "soap" for element "soap:Fault" is not bound"):
> {code}
> Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 13; Präfix "soap"
für Element "soap:Fault" ist nicht gebunden.
> 	at
> 	at
> 	at javax.xml.parsers.DocumentBuilder.parse(
> 	at$DocumentBuilderProxy.parse(
> 	at org.apache.wss4j.dom.util.EncryptionUtils.decryptXopAttachment(
> 	at org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(
> 	... 49 more
> {code}
> When I debug into {{decryptXopAttachment}} at {{}} and look at
what {{bytes}} it's trying to parse, they look something like this ({{<detail>}}'s contents
omitted for readability):
> {code:xml}
> <soap:Fault>
>     <faultcode>soap:Server</faultcode>
>     <faultstring>4</faultstring>
>     <detail>[...]</detail>
> </soap:Fault>
> {code}
> And of course, looking only at the body's contents attached via XOP, the "soap" prefix
isn't declared anywhere. It *is* declared in the {{<soap:Envelope>}} element, but since
that's not being included in the validation here because the attachment is being validated
on its own, that namespace declaration is missing.
> - When we return "regular responses", this error isn't triggered because the "soap" prefix
declared in the envelope isn't used in any of the bodie's elements, so all namespaces used
in the body are being declared in it.
> - If we disable MTOM, everything works fine - the response message will probably be parsed
in its entirety, including the envelope and its namespace declarations.
> - CAMEL-8663 seems to address this very issue on the Camel side (with help of CXF and
an endpoint property called {{org.apache.cxf.binding.soap.addNamespaceContext}}, used in {{org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor}}).
We need the same fix for standalone CXF/wss4j usage though.
> - I compared wss4j's behavior to metro/wsit using the same policy and metro includes
the envelope's namespaces in the element being attached like so:
> {code:xml}
> <S:Fault xmlns:S="">
>     <faultcode>S:Server</faultcode>
>     <faultstring>4</faultstring>
>     <detail>[...]</detail>
> </S:Fault>
> {code}
> So my conclusion is that WSS4J/CXF (forgive me if I used the wrong Jira project) should
repeat all namespaces declared in the {{<soap:Envelope>}} element in the xop-attached
body if MTOM serializaiton is enabled.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message