- 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