W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2001

Re: text/xml for SOAP is incorrect

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 20 Sep 2001 17:00:21 -0700 (PDT)
To: Mark Baker <distobj@acm.org>
Message-ID: <1001030421.3baa831531e12@mail.mnot.net>
Cc: Mark Nottingham <mnot@mnot.net>, "John J. Barton" <John_Barton@hpl.hp.com>, Andrew Layman <andrewl@microsoft.com>, xml-dist-app@w3.org, dave@scripting.com
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  
> 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/*" 

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

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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:15 UTC