Re: First draft of a list of goals

Jeffrey Mogul:
>    >(2a) The protocol must ALLOW correct caching, in which the user is
>    >guaranteed to see a valid copy of an object unless some network failure
>    >prevents it.
>    
>    Hmm... this begs the question of what's valid, which can only
>    be answered by a spec or model. I agree with the goal in
>    principal, but we'll have to see what the model looks like.
>    
>Probably I would define "valid" as
>        What the origin server would provide if it received the
>        request at approximately this instant.

I don't see how this definition of "valid" would fit in a HTTP caching
model.  How could a proxy cache ever serve a "valid" copy without
contacting the origin server?

Under the current draft, if a server at time T generates a response on
URI U which includes an Expires or Cache-control response header,

- this does _not_ mean that the server guarantees that the response
  it will serve for U will not change until some time T+X.

- rather, it means that the server finds it _appropriate_ for clients
  to give the response to a request for U at any time up to T+X.

Without using conditional GETs, caches can never present a response as
something the origin server _will say now_.

A web caching model must thus be built around the idea of an origin
server _giving permission to caches_ to present an old response as
something the origin server _would not mind saying now_.

Use of the term `valid entity' may be misleading, as the
`valid/invalid' distinction is also used when talking about RAM caches
in computers, where a `valid cache line' _does_ always hold the latest
memory contents.

Defining the protocol in terms of `appropriate entities' might be
better.

>-Jeff

Koen.

Received on Friday, 22 December 1995 00:12:54 UTC