W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: A modest proposal

From: Roy Fielding <fielding@beach.w3.org>
Date: Thu, 17 Aug 1995 16:28:43 -0400
Message-Id: <199508172028.QAA08825@beach.w3.org>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC