Re: Binding example discussion

Hi Mark,


On Tue, Jul 17, 2001 at 05:24:54PM -0400, Mark Baker wrote:
> My comments;
> 
> "If a SOAP envelope is not to be conveyed in the HTTP request, the
> request method used should be 'GET' (section 9.3)."
> 
> If SOAP isn't being used on the request, how do we know that GET
> semantics is what is desired?  I suggest removing that point.

Good point; the request method shouldn't be used to identify SOAP
messages; the content-type should (which isn't yet in this document).


> "If a SOAP envelope is to be conveyed in the HTTP response, it
> should be the complete content of the message body, as defined by
> RFC2616, section 6, with a '200 OK' status code (section 10.2.1)."
> 
> I've stated my position on this before, and will restate for
> emphasis.  I believe it's dangerous to require only a 200 response
> code, and would strongly recommend that my suggestions in [1] be
> followed.  Can I ask for a pointer to where the decision to use
> only 200 was made?

Mark, this is only a rough expression of an HTTP binding, to give the
group an idea of what I think a binding should look like; it isn't a
definitive HTTP binding description. The focus is on the overall
form, not the specific content.

500 vs. 200 is a fight for another day ;) 

(That said, thanks for the reference; I hadn't seen that, and it
makes some persuasive points)


> "If a SOAP envelope is not to be conveyed in the HTTP response, the
> response status code generated should be '204 No Content' (section
> 10.2.5)."
> 
> Suggest changing that to "If neither a SOAP envelope, nor any other
> information is to be conveyed in the HTTP response, the response
> status code generated should be '204 No Content' (section
> 10.2.5).".  I don't believe the WG wants to prevent other
> information coming back on a response, right?  Alternately, I'd
> suggest removing that sentence entirely as it would appear to fall
> outside SOAP's domain.

Good point. Will reword.


> "Additionally, implementations may make the following available:"
> 
> I'd also ask that the list of services be explicitly labelled as
> non-exhaustive.  New HTTP based services will continue to be
> defined over time.

See my first message to Henrik. I'm concerned about the requirements
that allowing an open-ended group of services will place on
implementations. It may be fine, we should just think through it...


-- 
Mark Nottingham
http://www.mnot.net/

Received on Tuesday, 17 July 2001 20:16:14 UTC