Loading ...
Sorry, an error occurred while loading the content.

SOAP Musts and Must Nots - from the spec...

Expand Messages
  • keithba@microsoft.com
    This is a little list I have started compiling of the MUST and MUST NOTs of the SOAP spec. Some of you may find this interesting. SOAP MUSTs and MUST NOTs 1. A
    Message 1 of 1 , Mar 21, 2001
    • 0 Attachment
      This is a little list I have started compiling of the MUST and MUST
      NOTs of the SOAP spec. Some of you may find this interesting.

      SOAP MUSTs and MUST NOTs
      1. A SOAP application receiving a SOAP message MUST process that
      message by performing the following actions in the order listed below
      2. A SOAP application MUST be able to process SOAP namespaces in
      messages that it receives. It MUST discard messages that have
      incorrect namespaces (see section 4.4) and it MAY process SOAP
      messages without SOAP namespaces as though they had the correct SOAP
      namespaces.
      3. A SOAP message MUST NOT contain a Document Type Declaration.
      A SOAP message MUST NOT contain Processing Instructions. [7]
      Envelope
      4. The element MUST be present in a SOAP message
      5. The element MAY contain namespace declarations as well as
      additional attributes. If present, such additional attributes MUST be
      namespace-qualified. Similarly, the element MAY contain additional
      sub elements. If present these elements MUST be namespace-qualified
      and MUST follow the SOAP Body element.

      Header
      6. The element MAY be present in a SOAP message. If present, the
      element MUST be the first immediate child element of a SOAP Envelope
      element.
      7. The element MAY contain a set of header entries each being an
      immediate child element of the SOAP Header element. All immediate
      child elements of the SOAP Header element MUST be namespace-qualified.

      Body
      8. The element MUST be present in a SOAP message and MUST be an
      immediate child element of a SOAP Envelope element. It MUST directly
      follow the SOAP Header element if present. Otherwise it MUST be the
      first immediate child element of the SOAP Envelope element.

      9. SOAP does not define a traditional versioning model based on
      major and minor version numbers. A SOAP message MUST have an Envelope
      element associated with
      the "http://schemas.xmlsoap.org/soap/envelope/" namespace. If a
      message is received by a SOAP application in which the SOAP Envelope
      element is associated with a different namespace, the application
      MUST treat this as a version error and discard the message. If the
      message is received through a request/response protocol such as HTTP,
      the application MUST respond with a SOAP VersionMismatch faultcode
      message (see section 4.4) using the
      SOAP "http://schemas.xmlsoap.org/soap/envelope/" namespace.

      Encoding rules for Headers
      10. A header entry is identified by its fully qualified element
      name, which consists of the namespace URI and the local name. All
      immediate child elements of the SOAP Header element MUST be namespace-
      qualified.

      Use of Header Attributes
      11. The recipient of a SOAP message MUST ignore all SOAP Header
      attributes that are not applied to an immediate child element of the
      SOAP Header element.

      Actor
      12. That is, a recipient receiving a header element MUST NOT
      forward that header element to the next application in the SOAP
      message path.
      13. This attribute MUST appear in the SOAP message instance in
      order to be effective (see section 3 and 4.2.1).

      mustUnderstand
      14. 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 (see section 4.4).
      15. The SOAP mustUnderstand attribute allows for robust
      evolution. Elements tagged with the SOAP mustUnderstand attribute
      with a value of "1" MUST be presumed to somehow modify the semantics
      of their parent or peer elements. Tagging elements in this manner
      assures that this change in semantics will not be silently (and,
      presumably, erroneously) ignored by those who may not fully
      understand it.
      16. This attribute MUST appear in the instance in order to be
      effective (see section 3 and 4.2.1).

      Body
      17. The Body element is encoded as an immediate child element of
      the SOAP Envelope XML element. If a Header element is present then
      the Body element MUST immediately follow the Header element,
      otherwise it MUST be the first immediate child element of the
      Envelope element.

      Fault
      18. The SOAP Fault element is used to carry error and/or status
      information within a SOAP message. If present, the SOAP Fault element
      MUST appear as a body entry and MUST NOT appear more than once within
      a Body element.
      19. The faultcode element is intended for use by software to
      provide an algorithmic mechanism for identifying the fault. The
      faultcode MUST be present in a SOAP Fault element and the faultcode
      value MUST be a qualified name as defined in [8], section 3. SOAP
      defines a small set of SOAP fault codes covering basic SOAP faults
      (see section 4.4.1)
      20. The faultstring element is intended to provide a human
      readable explanation of the fault and is not intended for algorithmic
      processing. The faultstring element is similar to the 'Reason-Phrase'
      defined by HTTP (see [5], section 6.1). It MUST be present in a SOAP
      Fault element and SHOULD provide at least some information explaining
      the nature of the fault.
      21. The faultactor element is intended to provide information
      about who caused the fault to happen within the message path (see
      section 2). It is similar to the SOAP actor attribute (see section
      4.2.2) but instead of indicating the destination of the header entry,
      it indicates the source of the fault. The value of the faultactor
      attribute is a URI identifying the source. Applications that do not
      act as the ultimate destination of the SOAP message MUST include the
      faultactor element in a SOAP Fault element. The ultimate destination
      of a message MAY use the faultactor element to indicate explicitly
      that it generated the fault (see also the detail element below).
      22. The detail element is intended for carrying application
      specific error information related to the Body element. It MUST be
      present if the contents of the Body element could not be successfully
      processed. It MUST NOT be used to carry information about error
      information belonging to header entries. Detailed error information
      belonging to header entries MUST be carried within header entries.
      23. The faultcode values defined in this section MUST be used in
      the faultcode element when describing faults defined by this
      specification. The namespace identifier for these faultcode values
      is "http://schemas.xmlsoap.org/soap/envelope/". Use of this space is
      recommended (but not required) in the specification of methods
      defined outside of the present specification.
      HTTP
      24. HTTP applications MUST use the media type "text/xml"
      according to RFC 2376 [3] when including SOAP entity bodies in HTTP
      messages.
      25. The SOAPAction HTTP request header field can be used to
      indicate the intent of the SOAP HTTP request. The value is a URI
      identifying the intent. SOAP places no restrictions on the format or
      specificity of the URI or that it is resolvable. An HTTP client MUST
      use this header field when issuing a SOAP HTTP Request.
      26. In case of a SOAP error while processing the request, the
      SOAP HTTP server MUST issue an HTTP 500 "Internal Server Error"
      response and include a SOAP message in the response containing a SOAP
      Fault element (see section 4.4) indicating the SOAP processing error.
    Your message has been successfully submitted and would be delivered to recipients shortly.