DO NOT REPLY [Bug 13618] - Implicit header support

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13618>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13618

Implicit header support





------- Additional Comments From tomj@macromedia.com  2003-10-23 17:54 -------
I believe this is the current state of CVS right now:

- Explicit request headers in WSDL are turned in to arguments to the stub 
functions (1.0 functionality)
- Non-WSDL headers can be set in the Call and Stub objects using the setHeader
() API (1.0 functionality)
- Response headers can be retrieved from the Call object using 
Call.getResponseMessage().getSOAPEnvelope().getHeaderByName()
- Response headers can be retrieved from the Stub after a call using the (post 
1.1) getResponseHeader() API

Axis 1.1 had some unfortunate changes made to it so that the getHeader() API 
in the stub would only return the headers that were ready to go out in a 
request.  I added the getResponseHeader() API so that stub users could get to 
the response headers easily.

I do not think that Axis should have the behavior that Sylvain was 
implementing, which is to keep a list of headers that once set, get sent for 
every operation called via a Stub.  He also had the header values get updated 
when the server returned a header with the same QName as one in the outgoing 
list.  This violates the ‘principle of least surprise’ and can be accomplished 
with more control by having the user set any headers for every request.

In summary, I believe that Axis SOAP header support is in good shape and this 
bug doesn’t address something we want to change.