Re: Issue: Table 17 (Spec part 2, 7.5.1.2) discrepancies

I took an action on last night's telcon to generalize the resolution 
proposed in [1] since it can also apply to other status codes.

Rationale for changes:

400 and 500 could both be generated by a server with or without a SOAP 
fault in the body of the response: table 23 defines responses including 
SOAP faults for both of these status codes, a HTTP server could also 
generate either prior to SOAP processing. The current text assumes that 
400 will not have a SOAP fault in the body and 500 will have a SOAP 
fault in the body

Proposed changes:

Paragraph before table 17.

<current>
Table 17 details the transitions that take place when a requesting SOAP 
node receives an HTTP status line and response header. Table 17 refers 
to some but not all of the existing HTTP/1.1 [RFC 2616] status codes. 
In addition to these status codes, HTTP provides an open-ended 
mechanism for supporting status codes defined by HTTP extensions (see 
[RFC 2817] for a registration mechanism for new status codes). HTTP 
status codes are divided into status code classes as described in [RFC 
2616], section 6.1.1. The SOAP HTTP binding follows the rules of any 
HTTP application which means that an implementation of the SOAP HTTP 
binding must understand the class of any status code, as indicated by 
the first digit, and treat any unrecognized response as being 
equivalent to the x00 status code of that class, with the exception 
that an unrecognized response must not be cached.
</current>

<proposed>
Table 17 details the transitions that take place when a requesting SOAP 
node receives an HTTP status line and response header. <new>For some 
status codes there are two possible next states: Fail and 
Sending+Receiving. In these cases the transition is dependent on the 
media type of the response. If the media type does not correspond to a 
SOAP message the next state is Fail. If the media type corresponds to a 
SOAP message the next state is Sending+Receiving.</new>

Table 17 refers to some but not all of the existing HTTP/1.1 [RFC 2616] 
status codes. In addition to these status codes, HTTP provides an 
open-ended mechanism for supporting status codes defined by HTTP 
extensions (see [RFC 2817] for a registration mechanism for new status 
codes). HTTP status codes are divided into status code classes as 
described in [RFC 2616], section 6.1.1. The SOAP HTTP binding follows 
the rules of any HTTP application which means that an implementation of 
the SOAP HTTP binding must understand the class of any status code, as 
indicated by the first digit, and treat any unrecognized response as 
being equivalent to the x00 status code of that class, with the 
exception that an unrecognized response must not be cached.
</proposed>

Table 17 row for 400, adding Sending+Receiving as a possible next state

<current>
Indicates a problem with the received HTTP request message. The problem 
can be malformed XML in the request message envelope. This operation 
SHOULD NOT be repeated with the same message content. The message 
exchange is regarded as having completed unsuccessfully.
</current>

<proposed>
Indicates a problem with the received request message.
</proposed>

Table 17 row for 500, adding Fail as a possible next state

<current>
Indicates that the response message contained in the following HTTP 
response entity body may contain a SOAP fault. Other internal server 
errors may be the cause of this status code. The local binding instance 
continues to receive the incoming message.
</current>

<proposed>
Indicates a server problem or a problem with the received request 
message.
</proposed>

Question: should we add Sending+Receiving as a possible next state for 
any of the other failure oriented status codes in table 17 ?

Comments ?
Marc.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0167.html

--
Marc Hadley <marc.hadley@sun.com>
XML Technology Center, Sun Microsystems.

Received on Thursday, 19 September 2002 12:24:14 UTC