W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: HTTP editorial issues (21Nov97)

From: Jim Gettys <jg@pa.dec.com>
Date: Mon, 26 Jan 1998 13:44:58 -0800
Message-Id: <9801262144.AA04790@pachyderm.pa.dec.com>
To: http-wg@cuckoo.hpl.hp.com, Ross_Patterson@ns.reston.vmd.sterling.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5281

>     8) (13.2.3) The third paragraph claims that "... HTTP/1.1 requires
>        origin servers to send a Date header with every response ...", but that
>        contradicts (14.19) where there are rules for when a server doesn't
>        have to supply a Date header.
>    10) (13.2.6) The second paragraph reiterates the claim that "... the HTTP/1.1
>        specification requires the transmission of Date headers on every
>        response".

This is left over from previous issues around allowing HTTP to be used
with clockless origin servers  (see issues list issue: NO_CLOCK).

I think the right fix is in the third paragraph of 13.2.3, which I've
rewritten to:

"HTTP/1.1 origin servers should send a Date header with every response if 
possible, giving the time at which the response was generated (see section 

And rewriting the paragraph of 13.2.6 to just say:

"Neither the entity tag nor the expiration value can impose an ordering 
on responses, since it is possible that a later response intentionally carries 
an earlier expiration time. The Date values are ordered to a granularity 
of one second."

>    14) (14.32) The second paragraph ends "Clients SHOULD include both header 
>        fields when a no-cache request is sent to a server not known to be
>        HTTP/1.1 compliant."  The fourth paragraph beings "HTTP/1.1 clients 
>        SHOULD NOT send the Pragma request-header."  This seems to be a 
>        contradiction. 

Yup; you are right.  The best thing to do, Henrik and I think, is just to 
delete the sentence "HTTP/1.1 clients SHOULD NOT send the Pragma 
request-header."  We think the other cases having to do with proxies are 
covered under the upgrade requirements already in the draft.  I think any 
rational implementation will likely just play it safe and always send "Pragma: 
nocache", rather than trying to optimize out the deprecated feature (Pragma); 
after all, you are cache busting, and can't expect stirling performance 
under these circumstances...

Thanks for your careful read; I really appreciate readers who
do as fine a job as you do.  And everyone everwhere benefits from
the reduction of errors in the standard.
				- Jim

Jim Gettys
Industry Standards and Consortia
Digital Equipment Corporation
Visting Scientist, World Wide Web Consortium, M.I.T.
jg@w3.org, jg@pa.dec.com
Received on Monday, 26 January 1998 13:46:20 UTC

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