RE: SOAP/XML Protocol and filtering, etc.

It's not that SOAPAction breaks HTTP per se.  It's more that it breaks
existing web infrastructure unnecessarily.  SOAPAction is mandated by the
spec, therefore clients must generate it and servers must process it.  As a
result a server implementation that ignores SOAPAction (regardless of the
fact that we haven't defined what SOAPAction's actual payload is) is
incorrect.  Similarly a browser or other client that doesn't include it
won't work either.  How can anyone be certain that the header will be
carried forward through existing proxies and firewalls?  How can a browser
generate a SOAP call, send it via POST and also generate the SOAPAction
header?  

What happens isn't that HTTP is broken, but rather there's a boatload of web
infrastructure that won't work as a result.  My perspective is also as a
purist -- SOAPAction bleeds information out of the SOAP envelope into the
carrier protocol.  This isn't clean from a protocol stack perspective since
a lower layer carrier protocol (HTTP in this case) now has specific
knowledge about its payload.

(Apologies for multiple messages to those on one or more of my responses.)

jeffrey kay <jkay@engenia.com>
chief technology officer, engenia software, inc. 
"first get your facts, then you can distort them at your leisure" -- mark
twain 
"golf is an endless series of tragedies obscured by the occasional miracle"
-- sports illustrated 
"if A equals success, then the formula is A equals X plus Y plus Z. X is
work. Y is play. Z is keep your mouth shut." -- albert einstein  

> -----Original Message-----
> From: David E. Cleary [mailto:davec@progress.com]
> Sent: Tuesday, May 08, 2001 11:45 AM
> To: Keith Moore; Dick Brooks
> Cc: xml-dist-app@w3.org
> Subject: RE: SOAP/XML Protocol and filtering, etc. 
> 
> 
> > it breaks compatibility with HTTP, it forces SOAP implementations
> > to depend
> > on non-portable features of HTTP client libraries and 
> proxies, it is not
> > portable across SOAP substrates, it is not reliable as a
> > filtering mechanism
> > (meaning it's inherently insecure), and it doesn't work 
> with encryption.
> 
> How does is break HTTP if HTTP 1.1 explicitly allows entity extension
> headers and contains explicit rules on how they should be 
> handled? Saying
> SOAPAction breaks HTTP is a red herring. It does no such thing.
> 
>

Received on Tuesday, 8 May 2001 13:12:29 UTC