Re: whenToUseGet-7 Why call it WEB Serivces? (was: RE: FW: draft findings on Unsafe Methods (whenToUseGet-7))

On Friday, April 26, 2002, at 05:25  PM, Roy T. Fielding wrote:
> What is necessary for the HTTP binding of SOAP is that the Request-URI
> used in a message identify the resource being accessed (which means
> either the service, if that is the only resource, or data within the
> service if it is acting as a namespace for resources).  The Request-URI
> must not simply identify a generic HTTP-SOAP gateway mechanism that
> does dispatching of the message contents according to some hidden
> identifiers within the SOAP envelope, because doing so introduces
> too many security holes.

Would this be addressed if SOAP-RPC didn't allow a method to be 
communicated in the envelope? Other, externally-defined uses of SOAP may 
shoehorn one in there, but I don't know how this could be stopped (the 
same is true of vanilla POST).

> and that when a failure or redirection
> occurs, the appropriate HTTP response code be given in the HTTP
> envelope,

Have you had a chance to review the WG's work [1] on this? I'd note that 
this is one of the areas where XMLP and RFC3205 do not agree.

> and also the appropriate cache-control mechanisms be
> included -- not at random, or by fiat of some clueless gateway
> interface, but by actually inspecting the SOAP response for the
> corresponding semantics and mapping those back out to the HTTP binding.

You've said that you don't expect SOAP to use GET. As I understand POST 
caching (please correct me if I'm wrong), it enables the response to a 
POST to be stored and served for future GETs to the same URI; not future 

If this is the case, are you saying that services which wish to make the 
a GETable envelope available should be able to do so by setting 
appropriate Cache-Control? Are there any other scenerios where 
manipulating cache-control for SOAP POST responses is useful 
(no-transform is already an issue [2] on the WG's plate)?


  (N.B. - editors' draft)

Mark Nottingham

Received on Saturday, 27 April 2002 15:41:07 UTC