W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: HTTP Caching Model?

From: Ari Luotonen <luotonen@neon.mcom.com>
Date: Thu, 15 Dec 1994 16:01:08 -0800 (PST)
Message-Id: <199412160001.QAA09663@neon.mcom.com>
To: "Daniel W. Connolly" <connolly@hal.com>
Cc: fielding@avron.ICS.UCI.EDU, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

> Why is that such a bad thing? The server can give a lot of information
> about what's available by giving several URI: headers.

Hmmm, I don't necessarily support this -- this wastes bandwidth.
Besides, the set of available versions may vary, so the proxy can
never be sure if it has all the presentations/knowledge of them
without going to the original server.

That's why:

> It had better
> go to the original server and get the real answer, if it doesn't have
> enough information locally.

Yes!  If it doesn't find a perfect match locally it goes to the
remote.  It may be that the remote tells to use the local copy, which
is ok, and still saves a lot of bandwidth.

> >1) Have the proxy revert to the source if it receives a request which
> >   includes a variant category that has not already been cached;

Definitely.

> >2) Tell the proxy about all the possible variants so that it can make
> >   the decision itself;

No; the list can't be guaranteed to be exhaustive after some period of
time.  Rather than futher complicating things with life times for this
information, have the proxy connect to remote every time in these
cases to make a check.

> >3) Use URCs so that the decision can be made within the client and not
> >   as part of the request.

Mmmmm (the way Marge Simpson sez it).

> >I think we can live with (1) for HTTP/1.0,
> 
> Bingo. I agree.

Jackpot. Me too.

Cheers,
--
Ari Luotonen				http://home.mcom.com/people/ari/
Netscape Communications Corp.
650 Castro Street, Suite 500
Mountain View, CA 94041, USA
Received on Thursday, 15 December 1994 16:01:54 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:09 EDT