Re: SOAP Response Caching

Hi Mark,

> On Wed, Sep 05, 2001 at 01:14:06AM -0400, Mark Baker wrote:
> > One important general comment.  After reading this, I get the
> > impression that it is for the use of SOAP that I like to call
> > "tunnelling" (which includes RPC), and doesn't attempt to cover the
> > REST-friendly use of SOAP.  I know you and I have been over the
> > differences before, but even if you're not yet convinced, hopefully
> > you at least acknowledge that SOAP can use its underlying protocol
> > in different ways.  I think you need to say this somewhere.
> 
> It's for any request/response use of SOAP; not just HTTP, but over
> TCP or any other underlying protocol you care to use. If you're using
> SOAP in some fashion that can leverage a particular underlying
> protocol's caching mechanisms to your satisfaction, a Module isn't
> necessary; go forth and cache. However, the semantics as well as
> real-world operational characteristics of many protocols - especially
> HTTP - may make caching SOAP difficult if not impossible.
> Additionally, some uses of SOAP will be across multiple bindings.
> Hence, a Module.

For sure, I didn't mean to suggest that it couldn't be used on protocols
other than HTTP.  But when this module *is* used on top of HTTP, the
interaction between caching models should be specified.

> My current view is that there are some good uses of HTTP caching in
> SOAP; it involves making a GET request (perhaps with a query), and
> getting a SOAP Envelope as a response payload.

I'll have to mull that one over.

> However, I'd model
> this as a SOAP one-way Message Exchange pattern, because the HTTP
> request isn't a SOAP request. It's still a Web Service, but it isn't
> SOAP on the request side.

I'm not sure I know what that means, primarily because I'm still not
sure what a "Web Service" is (or isn't).

> > SOAP bound to HTTP in a REST style would reuse the HTTP caching
> > model. If you wanted to suggest some extensions that would find
> > themselves into the SOAP header, that's ok, though unless they're
> > SOAP-specific I'd suggest doing it with HTTP headers.  
> 
> And I maintain that the HTTP caching model isn't interesting to reuse
> with SOAP, for most purposes.  It was designed years ago as an
> optimisation for hypertext browsing, based on distributed filesystem
> caching, and its implementation is probably the most irregular thing
> about HTTP.

I don't disagree with that last point, but why is the issue about it
being optimized for "hypertext browsing" a point against it being used
with SOAP?  SOAP is quite useful for that.

> SOAP's ability to target extensible blobs of XML at intermediaries
> is a godsend for caching; when I first learned of it, it was
> immediately clear that the best thing for caching and SOAP was for
> them to be used together, with these mechanisms.
> 
> On a personal note, I've built a career out of being something of an
> oracle for those (implementors, publishers and end users) lost in the
> maze of HTTP caching. Whilst reusing HTTP caching mechanisms in SOAP
> does give me a certain amount of job security, it also sentences me
> to quite repetitive work. Please, make it stop!

LOL.  Well, if the alternative is reinventing the wheel, I'm sure you'd
prefer to be repetitive, right?

> > Either way though, the Module itself will require an extended
> > SOAP/HTTP binding, since there's bound (pun not intended) to be
> > interactions - unless you want to suggest that the normative
> > SOAP/HTTP binding requires the use of "Cache-Control: no-cache"
> > (please don't 8-).
> 
> I think you mean 'no-store', not 'no-cache'.
> 
> Practically speaking, that is the current state; SOAP's use of POST
> in the HTTP binding means that no cache implementation I'm aware of
> will store any SOAP response. According to RFC2616, POST is cacheable
> with explicit directives (thogh I've seen that refered to as 'a
> mistake' by Those in the Know), so the group may need to specify
> Cache-Control on responses, just for completeness.

That would be very REST-unfriendly.  The developer should be in control
of that.

MB

Received on Monday, 10 September 2001 02:54:03 UTC