Re: Multiple objects in a single transaction: Making it more concrete

"Daniel W. Connolly" <>
Date: Mon, 11 Apr 1994 23:25:39 --100
Message-id: <>
Precedence: bulk
From: "Daniel W. Connolly" <>
To: Multiple recipients of list <>
Subject: Re: Multiple objects in a single transaction: Making it more concrete 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="us-ascii"
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Mime-Version: 1.0
Content-Length: 1448
In message <>, Ari Luotonen writes:
>> (BTW, as long as we're talking about cache servers, how do cache
>> servers handle negotiation of Content-Type?)
>Proxy becomes a client that can handle all the formats that the remote
>client has Accept:ed, and presents them by wrapping them to MIME and
>sending back.

Does the proxy assume that any format available in the cache is
preferable to all other formats? For example:

Fred really likes to read text/plain cuz it's fast, but his
browser supports applictaion/postscript too.
Joe really likes to read application/postscript cuz it looks good.

Fred bops to http://host/file.multi. It's not in the proxy cache,
so the proxy uses Fred's profile to get it from the remote source.
The remote source returns the text/plain version, as per Fred's

The Joe bops across the same link. Does the proxy server give
him the text version from the cache or does it notice that
the client profiles are different and go accross the wire?

(The proxy should also pay attention to the vary=... info
returned from the original remote fetch: if there is no vary=
parameter, it can (according to the spec) assume there are
no other formats available for that URI)

Note that the "any local format is preferable to all remote
formats" heuristic makes the proxy not quite invisible; i.e. the proxy
doesn't always act just like a fast version of the remote