[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SOAP and Firewalls

• To: xml-dev@l...
• Subject: Re: SOAP and Firewalls
• From: Paul Prescod <paul@p...>
• Date: Thu, 21 Feb 2002 15:01:02 -0800
• References: <3C754FA8.7DE092ED@p...> <200202212152.g1LLquj14432@d...>

Joe English wrote:
> 
> Paul Prescod wrote:
> 
> > * Semantics of HTTP: [...]
> > POST should not be used for safe, idempotent fetching of information.
> 
> I always thought it was the contrapositive: that operations which
> are not idempotent must use POST (or PUT or ... anything but GET).

If you go strictly by the HTTP specification then this is a grey area.
And of course anyone wanted to work around this in order to please a
language-lawyer could make the POST increment a useless counter.
Nevertheless, this is a violation of Web architecture:

 * http://www.w3.org/DesignIssues/Axioms.html

Practically it leads to problems because it leads to objects that are
not referencable by other objects and thus are not "on the web." 

> I was under the impression that idempotent POSTs were OK,
> (and even recommended for query-type operations with
> lots of long parameters, to avoid problems with buggy HTTP
> servers and overly-long URLs).

Yes, it is practically expedient in some circumstances. That's the
natural division between practice and theory. Sometimes it also makes
sense to POST the long query and have the server generate a resource
that represents the result. That result is now addressable so that the
query doesn't have to be duplicated in various references to it.

There has been a proposal for a QUERY method to handle this issue but I
think that that's the wrong solution, personally.

 Paul Prescod

• References:
  • SOAP and Firewalls
    • From: Paul Prescod <paul@p...>
  • Re: SOAP and Firewalls
    • From: Joe English <jenglish@f...>

• Prev by Date: RE: Two sides of SOAP (was RE: SOAP-RPC and R EST and security)
• Next by Date: RE: SOAP and Firewalls
• Previous by thread: Re: SOAP and Firewalls
• Next by thread: RE: On the use of HTTP as a Substrate
• Index(es):
  • Date
  • Thread