[SWS-465] Optional WS-Addressing request headers being treated as mandatory Created: 18/Dec/08  Updated: 04/May/12  Resolved: 25/Jan/09

Status: Closed
Project: Spring Web Services
Component/s: Core
Affects Version/s: 1.5.5
Fix Version/s: 1.5.6

Type: Bug Priority: Major
Reporter: Alan Boshier Assignee: Arjen Poutsma
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Windows XP, JDK 1.5


Using SimpleActionEndpointMapping results in wsa:MessageAddressingHeaderRequired errors being returned from a request unless that request specifies
a wsa:To and wsa:MessageID header. According to the WS-Addressing standard, only the wsa:Action header is mandatory.

The problem appears to lie in the hasRequiredProperties() method of org.springframework.ws.soap.addressing.MessageAddressingProperties. This method insists on

1. wsa:To being present
2. wsa:MessageID being present if either ReplyTo or FaultTo have been specified.

In the case of (2) above I was able to trigger the fault by omitting all of the MessageID, ReplyTo and FaultTo headers in my request, so it may be that the server-side stack has inserted a default "anonymous endpoint" value into one or both of the latter and that is triggering the error.

Comment by Arjen Poutsma [ 25/Jan/09 ]

Unfortunately, the required elements of the Message Addressing Properties are version-dependent. For instance, the http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810 version of the spec does require Action and To. So I guess i'll move the hasRequiredProperties() code over to AddressingVersion.

Comment by Arjen Poutsma [ 25/Jan/09 ]

With regard to the ReplyTo header, I believe that it defaults to "anonymous" when not given (in WS-Addressing 1.0, see http://www.w3.org/TR/ws-addr-core/#formreplymsg). So even when no ReplyTo or FaultTo is given in the request, a MessageID header is still required. The only way around this is to specify a "none" ReplyTo header.

Comment by Arjen Poutsma [ 25/Jan/09 ]

I believe this issue has been fixed. Could you please try a recent snapshot as of tomorrow, and see if it works for you?

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Sun Oct 21 01:29:21 UTC 2018 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.