- From: Roy Fielding <fielding@beach.w3.org>
- Date: Thu, 17 Aug 1995 16:28:43 -0400
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Hence this message. I'm going to pretend that we are designing
>a new protocol, not changing an existing one, to avoid confusing
>the issue with debates about broken implementations or minimal
>changes. Until we can agree on what we want the protocol to do, it's
>pointless to argue over how it does it.
That is not within our guidelines for 1.x. I do not believe in
creating large entry barriers between minor protocol revisions,
and HTTP versioning was designed to prevent it.
>Let's assume that the HTTP 1.1 spec, and all subsequent ones,
>explicitly state the tautology that "an implementation not conforming
>to this specification does not conform to this specification." Any
>"broken" browsers, servers, or clients will simply not be able to claim
>conformance to HTTP 1.1, so it is not necessary to write that spec to
>allow non-conforming implementations. At the same time, the robustness
>principle applies: we should not write a spec that leads to a
>"fragile" system.
Yep. I claim that both are already true given the mechanisms we
have already discussed and which are within the scope of 1.1.
That includes:
Date: (no change necessary)
Expires: (no change necessary)
Last-Modified: specify that LM > server time must not be given
If-Modified-Since: specify that IMS > server time is invalid
Pragma: add "no-cache", "private", and "max-age"
Content-MD5: no problemo
Content-CRC: no problemo
Transfer-Encoding: chunked
>So how would I design HTTP 1.1, if I were in charge?
>
> (1) Servers may send a header field explictly controlling
> caching. The spec could either be simple, something like
> Dont-Cache-This-ever:
> or a little more complicated:
> Caching-allowed: [never | always | byClient | byProxy]
> to allow for unanticipated future developments.
Pragma is already set up to do this, and more (the above does not
include the functionality of max-age).
> (2) Clients and proxies need a foolproof way to validate cache
> entries. "If-modified-since" seems to be of questionable
> reliability.
Solved. IMS is only of questionable reliability when users are prevented
from controlling their own cache, or when servers send out invalid data.
> (3) Servers may send Expiration information for cachable
> objects. (Expiration is not meaningful for noncachable
> objects.) Prior to the expiration time, a client or proxy
> need not validate the cached object with the server, but
> MUST provide a means for the user to request validation.
>
> The Expiration header looks like this:
> Expiration-info: Expires-time server-current-time
Unnecessary. That is why Date is given in responses.
....Roy T. Fielding Department of ICS, University of California, Irvine USA
Visiting Scholar, MIT/LCS + World-Wide Web Consortium
(fielding@w3.org) (fielding@ics.uci.edu)
Received on Thursday, 17 August 1995 13:30:44 UTC