Re: text/xml for SOAP is incorrect

Quoting Mark Baker <distobj@acm.org>:

> > Without going into REST/no-REST issues, I think these directives can
> > be applied, as they would be considered advisory; if an intermediary
> > has other knowledge with greater precedence (such as out-of-band
> > configuration, or explicit targeting by a header) that it should
> > perform an operation, it can. They're there more to protect from
> > devices that would act without a specific directive, which is allowed
> > by the HTTP.
> 
> But an entirely opaque content type would (theoretically) ensure that
> only SOAP processors could transform the message.  That's the  
concern
> here, right?  I think application/soap does just that.  

This doesn't assure that at all; it only removes the risk that a processor 
which uses content-type in a heuristic will mis-identify SOAP messages 
as otherwise. Other heuristics may be in use (although Content-Type is 
the most obvious).


> Are you aware of any intermediary that transforms "application/*" 
bodies?

No, but there's nothing to stop one. I'm not saying that no-transform will 
guarantee anything, but it is the directive to use if you want your message 
to have the semantic of "don't mess with me."

> I'll have to give the no-cache issue more thought.  I haven't
> seen it used with POST, so I'm not sure how or why it's important
> in that context.  But I currently don't see a need to say anything
> beyond what HTTP already says about it.  If somebody finds a good
> use of it over a non-SOAP POST, then it can also be used with a
> SOAP POST.

I think it would be included largely for completeness; although 2616 
allows POST to be cached, I've heard that considered a mistake by 
several of those involved, and practically speaking, no one caches POST.


Cheers,

Received on Thursday, 20 September 2001 20:00:44 UTC