Re: [i95, i22] - Proposal for clarifying use of SOAPAction

Henrik Frystyk Nielsen wrote:
> 
> >"The presence of a SOAPAction header in a HTTP POST request
> >indicates that the entity-body of the request is a SOAP
> >message. The value of the SOAPAction header field is used to
> >indicate the intent or logical target of the request in a
> >manner readily accessible to the HTTP server."
> 
> The entity-body doesn't have to be only a SOAP message - because we can
> have nested bindings, it could be layered within a MIME multipart or
> some other format. What about
> 
> "The presence of the SOAPAction HTTP request header field indicates that
> this is a SOAP HTTP request, which means that it contains a SOAP message
> intended for a SOAP processor. The value of the SOAPAction header field
> is used to indicate the intent of the SOAP HTTP request in a manner
> readily accessible to the HTTP server."
> 
ok

> The term "logical target" seems to conflict with the request-URI which
> is the destination of the request.
> 
By logical target I was trying to bring out that there may be some
additional level of dispatching done by the HTTP endpoint and influenced
by the SOAPAction header. e.g. an implementation might have a core
engine into which services are plugged. The core engine manages the HTTP
endpoint and dispatches messages to services by matching the value of
the SOAPAction header to a service registration.

> >How about the following instead:
> >
> >"If a HTTP endpoint that only supports SOAP HTTP requests
> >receives a request without a SOAPAction header then the server
> >SHOULD return a HTTP 425 (SOAPAction Required) status code to
> >the client."
> 
> I was thinking about this formulation as well but shied away from it
> because HTTP endpoints are likely to support GET and HEAD as well which
> are not covered by at least this SOAP/HTTP binding. The text reads as if
> 425 I always required but it is only for certain requests (SOAP HTTP
> requests).
> 
I see what you mean. We could make my modified text more specific:

"If a HTTP endpoint that only supports SOAP HTTP requests
receives a HTTP POST without a SOAPAction header then the server
SHOULD return a HTTP 425 (SOAPAction Required) status code to
the client."

or we could use your original text:

"If a SOAP HTTP request is required but no SOAPAction header field is
present then the server SHOULD use a 425 (SOAPAction Required) status
code"

I think they both convey the same intent but that the former spells out
the conditions under which a 425 might be returned whereas the latter is
more open to interpretation. Given that this is in the context of the
part of the specification that defines the SOAP HTTP binding I prefer
the former but I am open to persuasion.

> >To address i22 how about adding the following paragraph:
> >
> >"If a HTTP request contains a SOAPAction header but the HTTP
> >entity body is empty or contains a malformed SOAP message then
> >the server SHOULD return a HTTP 400 (Bad Request) status code
> >to the client."
> 
> Given that it is a SOAP HTTP request, it might be better to use a SOAP
> Client fault.
> 
I wondered about that too. I would be happy either way as long as it is
specified.

Marc.

--
Marc Hadley <marc.hadley@sun.com>
Tel: +44 1252 423740
Int: x23740

Received on Friday, 27 April 2001 06:55:49 UTC