W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

Re: LC Comments: Web Method Feature (really: REST & SOAP)

From: Laird Popkin <laird@io.com>
Date: Mon, 08 Jul 2002 20:00:49 -0400
To: Grahame Grieve <grahame@kestral.com.au>, <xml-dist-app@w3.org>
Message-ID: <B94F9FF1.295FE%laird@io.com>

Squid honors the nocache headers, etc. You can also fake out the less
intelligent caches (e.g. AOL) by requiring HTTP AUTH or constructing URL's
so that they look like they're CGI's.

My gut reaction is that you typically want to _not_ cache any SOAP-stye
messaging, in order to avoid the application-level collisions (e.g. "I want
to know who asked for that information, even if the answer could be cached")
but may well want to cache data associated with that messaging (i.e. Pass
data by reference to a URL, and cache the contents of the document at the
URL). So I think the application author can control this...

- LP

On 7/8/2002 18:32, "Grahame Grieve" <grahame@kestral.com.au> wrote:

> 
> 
>> 
>> 
>>> If you do not tunnel, you allow HTTP-knowledgable software
>>> components to do their job:
>>> 
>>>  * Squid can cache based on URIs, method names and cache headers
> 
> oh - this is a good thing?
> 
> The problem with this is that cache's are not very controllable,
> and they are a significant problem for applications that must
> maintain tight control over the currency of data in the client.
> The cache doesn't fully understand the semantics of the data,
> so participates badly in the dynamics. This is a good reason
> to tunnel, in practice, to keep cache's out of the picture.
> (and since proxies actually seem to ignore http guidelines
> in the field, it's doubtful that that something more
> challenging can be made to work)
> 
> Grahame
> 

-- 
Received on Monday, 8 July 2002 20:00:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT