- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 14 Jun 96 16:46:44 MDT
- To: "David W. Morris" <dwm@shell.portal.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> 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
browsers.
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.
-Jeff
Received on Friday, 14 June 1996 16:56:05 UTC