W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: Ordered 'opqque' validators

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Tue, 06 Feb 1996 17:07:49 -0800
To: Peter J Churchyard <pjc@trusted.com>
Cc: http-caching@pa.dec.com
Message-Id: <9602061707.aa10335@paris.ics.uci.edu>
> Is anybody planning to do any modelling of these protocols?

Yes, many people already have -- take a look at all four WWW
conference proceedings.  I am sure that more models will be
made and analyzed in the future.

> As I understand it, millions of http clients and servers may be
> expected to implement a protocol thats designed to be used in a
> continental mega cache  - continental mega cache  situation. Wouldn't this
> rather special situation better be handled by a specific protocol for that
> environment?

No -- if any caching is possible, the choice of how and where the
caches exist cannot be made by the protocol.  Any client capable of making
an HTTP request is also capable of retaining a cache.  We already know
that it is both possible and desirable for those caches to be layered.
We also know that not all requests are cachable, and that finer control
of caching options is desired for some resources.  Therefore, what we need
in the protocol is a way of expressing those options and the semantics of
what is being expressed.

Now, let's assume that there does exist a different protocol called MEGA.
In that case, we have

         HTTP              MEGA                  HTTP
     UA  ---->  Org Proxy  ----> Regional Proxy  ---->  OS

Given this configuration, what are the requirements on HTTP?

The answer is: the same as they would be if MEGA=HTTP, since HTTP must
be used to communicate the requirements from the origin to the User Agent
no matter what exists in the middle.  Note that in order to work, MEGA
must be as flexible and extensible as HTTP and must also obey HTTP's
requirements on intermediaries, which goes a long way toward explaining
why people just use HTTP for this purpose.

[BTW, for a long time now the initial application of HTTPng has been
 that of a MEGA protocol]

The design requirement obtained from all this is that HTTP must
be capable of supporting, or at least not preventing, multiple
caching intermediaries along the request/response chain.  This was
not decided overnight -- I have been working on it for two years now.
I already know it works (in fact, it even works without any of the
improvements we have talked about here, provided that the user has
a working Reload button).  It will work even better once we have
a good written description for cache-control.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/
Received on Wednesday, 7 February 1996 01:31:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 November 2008 20:51:42 GMT