axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Graham" <sggra...@us.ibm.com>
Subject Re: where are handlers (sb headers) blown away?
Date Fri, 02 Feb 2001 22:19:37 GMT
sorry folks
The subject line of my original posting was misleading.
We blow away headers (technically headerEntries) not handlers.

Dynamically changing input and output chains are fascinating but of
questionable use :-)

++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
<<Pithecanthropus Erectus>>
Emerging Internet Technologies
++++++++


Steve Graham/Raleigh/IBM@IBMUS on 02/02/2001 05:05:55 PM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  where are handlers blown away?



Folks:
I propose the following mechanism to handle mustUnderstand and
header deletion/redirection semantics in SOAP.

This is based on the interpretation that the entire contents of
the Axis Engine (eg the sum of all the handlers on the input path
upstream of the dispatcher) is considered the SOAP application.

Each individual handler is *not* a SOAP application (I used to
believe a handler could be interpreted as a SOAP application, but
I have now recanted).

- Axis Engine does mustUnderstand check before any chain is invoked
  - This check is required by SOAP v1.1 section 2
  - check builds a selection comprised of each HeaderEntry in the
    message that is both targeted for the Axis Engine and is marked
    MustUnderstand
  - Engine verifies that for each HeaderEntry in the selection there
    is a handler on the pre-processing set (eg upstream of a dispatcher)
    that canHandleBlock() returns true for that kind of headerEntry
  - If there are HeaderEntries in the selection for which there are
    not handlers in the chain which can handle that headerEntry, the
    MustUnderstand fault is thrown.

- Handlers do not delete HeaderEntries.  Handlers mark headerEntries
  for delete.  Note: Handlers may also mark handlers for "copy/forward"
  by including an actorURI indicating the new target actor for the
  headerEntry

- It is the responsibility of the Dispatcher to execute the headerEntry
  deletes and copy/redirection.  The Dispatcher examines the message
  before dispatching it.  For each header marked delete, it deletes it.
  For each header marked for copy/redirect, it changes the actorURI to
  the new target actorURI specified by the handler.  For all other
  headerEntries targeted for the dispatcher's Axis Engine, it deletes
  those headers.

By delaying the deletes of the headers we satisfy some scenarios Yuhichi
described where logging happened only after a handler for DigSig
processed a MustUnderstand headerEntry.

thoughts?
sgg

++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
<<Pithecanthropus Erectus>>
Emerging Internet Technologies
++++++++




Mime
View raw message