Issue #93

I was supposed to present this summary of issue 93
at the F2F but since we ran out of time, here it is
in text form.

Issue 93:
=========
Paul Kulchenko asked:
   Hi, All! Since it's possible to return a Header from
   server to client also, what should the client do if
   this header has mustUnderstand attribute or wrong actor?
   Best wishes, Paul.

Summary of discussion:
======================
What does the spec say:
   If a header element is tagged with a SOAP mustUnderstand
   attribute with a value of "1", the recipient of that
   header entry either MUST obey the semantics (as conveyed
   by the fully qualified name of the element) and process
   correctly to those semantics, or MUST fail processing
   the message

There are really 3 choices for the client:
  - Ignore it
  - Fault back to the server
  - Fault back to the client

As Henrik points out "Ignore it" is not a valid choice since
this would violate the spec.

Mark Nottingham noted that it will probably be application
dependent.

Dick Brooks said:
  I would have to say it is important to specify client side
  behavior with regards to processing SOAP headers within
  response messages.

Noah Mendelsohn commented(in short):
  nobody is forcing the responder to use mustUnderstand
  headers in situations where they are going to cause trouble

Noah's comment raises the issue that Mike Deem mentioned:
  A use case that recently came up: the service sends arbitrary
  "session" state back to the client in a header.  The client
  needs to echo that header back to the service in future
  requests or things won't work.  It makes sense for the server
  the set mustUnderstand="1" and expect the client to generate
  a fault for the application should it not understand this
  header.

That's about all that was said.  It seems pretty clear that
the spec says a fault needs to be generated.  What happens
with the fault (either nothing, sending it back to the server
or just faulting on the client) is an application specific
problem that is outside the scope of the spec.
As such, I would propose that we reply to Paul stating this
and closing the issue as resolved.

-Dug

Received on Sunday, 10 June 2001 20:55:01 UTC