SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Client Handling of SOAP Headers with MustUnderstand Attribute in XMLP/SOAP Messages

leora avatar
leora
13 diapositives · 268 Views · Aug 14, 2014

This discussion addresses how clients should handle SOAP headers that possess the mustUnderstand attribute or are directed to the wrong actor. Paul Kulchenko poses a query regarding client behavior upon receiving such headers, leading to the consideration of three possible actions: ignoring, faulting back to the server, or faulting back to the client. It is emphasized that the specifications mandate that these headers must not be ignored. The proposal aims to clarify that the processing model must prioritize generating faults based on client-side policies, defining how to manage SOAP headers in response messages effectively.

Client Handling of SOAP Headers with MustUnderstand Attribute in XMLP/SOAP Messages - slide 1
01 / 13Client Handling of SOAP Headers with MustUnderstand Attribute in XMLP/SOAP Messages
1 / 17

Télécharger la présentation

Client Handling of SOAP Headers with MustUnderstand Attribute in XMLP/SOAP Messages
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  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”