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 Sun, 04 Feb 2001 01:29:30 GMT
Yuhichi:
Section 2 of the soap spec indicates that:

"Verify that all mandatory parts identified in step 1 are supported by the
application for this
message (see section 4.2.3) and process them accordingly. If this is not
the case then discard the
message (see section 4.4)."

It seems to me that the mustUnderstand checking must happen up front in
order to
remain compliant with soap spec.  Don't you agree?

Interesting point about output chain.  Are you imagining that some
component will insert
a header in the response envelope that will be targetted at some
intermediary?

Interesting.  Can you give me a scenario that demonstrates this?

In general, I would not have a transport listener implement anything that
is related
to SOAP semantics.  If we agree that we need to check this on the output
chain, then
I imagine that it would need to happen by some component in the chain
before the
message is given to the transport sender.

sgg

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


"Yuhichi Nakamura" <NAKAMURY@jp.ibm.com> on 02/03/2001 10:14:58 AM

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

To:   axis-dev@xml.apache.org
cc:
Subject:  Re: where are handlers (sb headers) blown away?




Steve,
Although I do not like pre-processing of MustUnderstand,
except for this, I think you get a point.
I suggest to remove the pre-processing portion, and add a post
-processing.  Before executing header removal
etc, the dispatcher checks if mustUnderstand headers are
processed.  This is naive, but covers all cases, I think.

p.s.  Output chain is processed in the same manner?  So,
TransportListener for example has to perform header
removal, etc.

Regards,

Yuhichi Nakamura
IBM Research, Tokyo Research Laboratory
Tel: +81-46-215-4668
FAX: +81-46-215-7413


From: "Steve Graham" <sggraham@us.ibm.com> on 2001/02/03 07:19

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

To:   axis-dev@xml.apache.org
cc:
Subject:  Re: where are handlers (sb headers) blown away?



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