Re: text/xml for SOAP is incorrect

> One of the issues I've been meaning to raise is that SOAP messages
> should have 
>    Cache-Control: no-store, no-tranform
> 
> always appended in HTTP. However, this won't do any good for
> intermediaries that don't pay attention to them, for whatever reason.
> I also know that some will object to this for philosophical reasons.

I object to both no-store and no-transform, but for practical reasons,
not for philosophical ones.

Passing either instruction to a SOAP/HTTP intermediary is instructing
that intermediary not to transform or cache it, even if it knows about
SOAP.  That means that headers can't be added, removed, modified,
etc..

(yes, this is presupposing a REST use of SOAP.  A tunneled use would
ignore Cache-Control at the SOAP layer)

> Using a different content-type identifies the message clearly as a
> SOAP message, lessening the likelyhood that it will match the
> heuristic of an intermediary looking for XHTML, etc. In the process,
> this will also lessen the overhead imposed on SOAP messages by such
> intermediaries, as outlined earlier.
> 
> What are the strong reasons for leaving it at application/xml,
> instead of definng a SOAP-specific content-type? What great harm will
> this cause? The only argument that I've seen is based on a slippery
> slope fallacy.
> 
> For that matter, one could argue that SOAP's content-type should be
> text/plain; after all, that describes the format; the fact that it's
> text with an XML structure imposed is irrelevant.

The best way of ensuring that only SOAP processors manipulate SOAP
messages is to make the Content-Type as opaque as possible.
text/* isn't very opaque, because there's certain assumptions that
can be made about the content (EOL, encoding, etc..).  application/*
is completely opaque, though using "+xml" with it makes it less so as
Larry pointed out.  From that POV, application/soap looks even more
attractive.

MB

Received on Thursday, 20 September 2001 17:00:35 UTC