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

Note: thread limited to <xml-dist-app> in order to avoid cross posting

>The proposed text doesn't address i22, i.e. what to do if you 
>get a HTTP request with a SOAPAction header but no SOAP 
>envelope in the body. I'd also like to propose a couple of 
>minor edits, see below

Good point. By clarifying that a SOAP HTTP message is indicated by the
presence of the SOAPAction header field, this means that the processing
will have to be done by a SOAP processor and so if the body is not a
SOAP envelope, the processor will respond with a Client fault [10]. 

>Henrik Frystyk Nielsen wrote:
>> 
>> The presence of the SOAPAction HTTP request header field indicates 
>> that this is a SOAP HTTP request. The value of the SOAPAction header 
>> field is used to indicate the overall intent of the SOAP HTTP request

>> with the purpose of providing the recipient with a hint about what
the 
>> SOAP message contains:
>> 
>This still sounds a little vague, how about the following instead:
>
>"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."

The term "logical target" seems to conflict with the request-URI which
is the destination of the request.

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

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

>> The presence and content of the SOAPAction header field MAY be used
by 
>> servers such as firewalls to appropriately filter SOAP HTTP request 
>> messages. It SHOULD NOT be used as an insecure form for access 
>> authentication.
>> 
>Should the last sentence read "It SHOULD NOT be used as an 
>insecure form of access authorisation." ? i.e. replace "for" 
>with "of" and "authentication" with "authorisation".

ok

Thanks!

Henrik

[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x95
[2] http://www.w3.org/2000/xp/Group/xmlp-issues#x22
[10] http://www.w3.org/TR/SOAP/#_Toc478383507
[11]

Received on Thursday, 26 April 2001 16:10:09 UTC