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

Re: Mozilla and If-Modified-Since

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Fri, 14 Jun 96 16:46:44 MDT
Message-Id: <9606142346.AA05382@acetes.pa.dec.com>
To: "David W. Morris" <dwm@shell.portal.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/940
    > Re: "if-modified-since: tuesday, 24-Jan-95 00:24:37 GMT; length=116"
    > appearing to be dropped:
    > This was not a case of something "falling off the map", it was an
    > explicit choice to support entity tags instead.
    What is a tiny bit unfortunate is that we didn't allow for optional
    parameters on the last-modified header. If nothing else, that would
    warn implementors to be prepared to receive garbage with the date.

I think it would be a bad idea to put this kind of thing in the
grammar, just because a few implementors stuck it into their

However, a straightforward application of the Robustness Principle:
                "Be liberal in what you accept, and
                   conservative in what you send"
(cf RFC1122, and others) suggests that once you've parsed to the
end of a valid HTTP-Date, you should ignore the rest of the
If-Modified-Since header-value.

Although there is no specific discussion of the general Robustness
Principle in the HTTP/1.1 draft, I think a reasonable interpretation
of the IETF culture would apply this principle whenever it isn't
specifically contradicted.  And, at any rate, section 3.3.1 almost
gets there, saying

  Note: Recipients of date values are encouraged to be robust in
  accepting date values that may have been sent by non-HTTP
  applications, as is sometimes the case when retrieving or posting
  messages via proxies/gateways to SMTP or NNTP.

Received on Friday, 14 June 1996 16:56:05 UTC

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