1 / 13

Issue 93

Issue 93. Mu at Client (mustUnderstand on client side). Doug Davis XMLP F2F June 2001. Paul Kulchenko asked:.

leora
Download Presentation

Issue 93

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Issue 93 Mu at Client (mustUnderstand on client side) Doug Davis XMLP F2F June 2001

  2. 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.

  3. Client Behavior • 3 Choices • Ignore it • As Henrik pointed out this is definitely wrong – spec says it can not be ignored • Fault back to the server • Fault back to the client • Mark Nottingham noted that it will probably be application dependent (so either 2 or 3)

  4. Proposal • Basically, leave it as is… • The processing model must not be ignored • Use this specific case in an example and state that a Fault must be generated but how the application chooses to act on it is up to the implementation • Clarify the Spec to clearly state that, except for the server side of the RPC case, where faults are sent is an implementation detail or application specific

  5. Processing Model A XMLP/SOAP application receiving a XMLP/SOAP message MUST process that message by performing the following actions in the order listed below: • Identify all blocks of the XMLP/SOAP message intended for that application (see section 4.2.2) • Verify that all mandatory blocks 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). The processor MAY ignore optional blocks identified in step 1 without affecting the outcome of the processing. • If the XMLP/SOAP application is not the ultimate destination of the message then remove all blocks identified in step 1 before forwarding the message.

  6. Two Issues • What does the Spec say about Faults? • Client behavior

  7. Spec on Faults • In the RPC case the Spec implies that server generated Faults should be sent back to the client • The Spec is silent on what to do with Faults in all other uses of SOAP (non-RPC) • Implementation specific detail (?)

  8. Client Behavior • 3 Choices • Ignore it • As Henrik pointed out this is definitely wrong – spec says it can not be ignored • Fault back to the server • Fault back to the client • Mark Nottingham noted that it will probably be application dependent (so either 2 or 3)

  9. Client Behavior • Spec should clearly state what to do • Dick Brooks: …I would have to say it is important to specify client side behavior with regards to processing SOAP headers within response messages.

  10. Server Behavior • Server was stupid to send it in the first place • Noah Mendelsohn:…nobody is forcing the responder to use mustUnderstand headers in situations where they are going to cause trouble • But, what about correlation Ids?

  11. 3rd Issue? Implementation Detail • Does noticing the fault but choosing to do nothing with it violate the Spec? • Is this the same thing as ignoring it? • Must there be some change in semantics as a result of the fault?

  12. Proposal • Basically, leave it as is… • Clarify the Spec to clearly state that, except for the server side of the RPC case, where faults are sent is an implementation detail or application specific • The processing model must not be ignored • Use this specific case in an example and state that a Fault must be generated but how the application chooses to act on it is up to the implementation • Clarify the Processing Model • Replace “discard the message “ with “generate a fault”

More Related