- From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
- Date: Fri, 27 Apr 2001 11:12:37 -0400 (EDT)
- To: "'Doug Davis'" <dug@us.ibm.com>, <xml-dist-app-request@w3.org>
Hi Doug, >That's one of the problems with it - if it can't be computed >based on the contents then how should it be produced when you >go from SMTP to HTTP? You carry over the SOAPAction header field from the HTTP request to the SMTP message, which is what ebXML for example proposes. This is just a matter of specifying this in the protocol binding. If there are MIME header fields then it is fairly simple define a SOAP module (for example a routing module, see [1] where you will notice an "action" element) that can carry the value. >But again, isn't this part of problem. The SOAP spec doesn't >really say anything about how it should be used (expect >"possibly" to filter things). So here we have a field that can >be empty or it can contain something and it can be used to >filter or it can be used to dispatch or it can be used to >route or it can be ignored. This doesn't sound like the SOAP >spec really says much about it - other than it must be there >for HTTP. To me if a field must be there then there must be a >clear definition of what its value should be and how it should be used. There are two parts - the existence of the header field and the value. The existence has clear semantics to the caller - the SOAP endpoint determines the value which means that it can use it for whatever it wants. There is no way that we can prohibit people from doing internal dispatching on various fields - people use user-agent, cookies, and what-not in HTTP today and there is in general no problem with this. >I guess I'm wondering why it matters? Unless I'm mistaken a >JSP, cgi-bin, servlet... don't require a special header >indicating what type of request it is, so why does SOAP? There are many places where I can simply POST an XML document which happens to be a SOAP document but where I don't expect it to be processed as a SOAP message (at least as a result of the HTTP request/response interaction). We could have used the media type but that makes it impossible to distinguish posting a SOAP message as just data vs. as a SOAP HTTP request. Also, it is much harder to define nested bindings like MIME multipart/related [2] as they already have defined media types and we would then have to special case this or have the server look through the message to see whether there is a SOAP message hidden in there somewhere. Thanks! Henrik [1] http://www.w3.org/2001/03/WSWS-popa/paper41 [2] http://www.w3.org/tr/soap-attachments
Received on Friday, 27 April 2001 12:27:51 UTC