- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Mon, 7 May 2001 07:57:39 -0700
- To: "Jeffrey Kay" <jkay@ENGENIA.COM>, "Dick Brooks" <dick@8760.com>, "Martin Gudgin" <marting@develop.com>, "Jake Savin" <jake@userland.com>, "Painter, Philip" <Philip.Painter@compaq.com>, "Daniel Barclay" <Daniel.Barclay@digitalfocus.com>
- Cc: <xml-dist-app@w3.org>
>So this is one of the more fascinating issues to me in SOAP. >I'm in the "anti" category for the SOAPAction. I consider it >at best a duplication of what the URI should be. If I may direct the attention at the proposed wording then this is absolutely not what it says http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0053.html >Overall, I'd like to see the SOAPAction header just go away. >I've heard arguments that it's necessary for SOAP >intermediaries, but I'm not certain I buy that either. If an >XMLP intermediary must understand the SOAPAction header, then >it's next stop is to process some amount of the XML encoded >within the message. No, there is no assumption that this is the case. One can claim that many of the "content-*" header fields are redundant: Take the content type which one might be able to figure out by sniffing the contents. However, this is not the point - the point is for an HTTP application that only deals in HTTP header fields, request methods, and status codes to be able to figure out what is going on without having to dive into XML or other languages. In that sense, SOAPAction provides a mechanism that allows HTTP servers and client to indicate their intent and to describe the contents of a message. This is in my mind a Good Thing (tm). Henrik
Received on Monday, 7 May 2001 11:37:16 UTC