Re: A modest proposal

Balint Nagy Endre (bne@bne.ind.eunet.hu)
Fri, 18 Aug 1995 05:42:57 +0200 (MET DST) 

> >Jeffrey Mogul writes:
> >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.
> Roy T. Fielding's answer:
> 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
> ...
Is the discussion on changing pragma no-cache semantics and introducing
pragma private for old no-cache semantics?

I see Content-MD5, Content-CRC Transfer-Encoding: chunked first time. Maybe I
should subscribe to www-talk to be enough informed?

If the 1.1 spec defines response headers like
Content-MD5, (Content-MD3 ? - see RFC1810 on MD5 performance)
Content-CRC, (maybe Content-CRC16 and Content-CRC32 to have more options?
	      about this I'm less sure, than MD3)
then when somebody or some application is in doubt, can issue a HEAD request
to get those headers, and re-check the cache content against them.
I like this kind of extension!

Only MD5 can be stated as CPU-intensive, CRC and MD3 can be computed rapidly
in case, when the origin server is in doubt about cached values, and can be
supplied to the server as meta-data, if they are stored separately from the
document. (I mean the technical impossibility of in-lineing 
like <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> in the HEAD element.
Not fully true for CRCs.)

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>