On 07/22/2016 01:38 PM, William A Rowe Jr wrote:
RFC 7231 § 7.1.1
RFC 7232 § 2.2
Okay, at least we're looking at the same sections then. But I'm not
finding support for your statement that we must replace completely
unintelligible Last-Modified values with current timestamps. The closest
I found was this:
An origin server with a clock MUST NOT send a Last-Modified date that
is later than the server's time of message origination (Date). If
the last modification time is derived from implementation-specific
metadata that evaluates to some time in the future, according to the
origin server's clock, then the origin server MUST replace that value
with the message origination date.
which does not apply to completely invalid data, just future timestamp
metadata. A "Last-Modified: complete-junk" header coming from a CGI
implementation is not a "future" timestamp; it's complete junk, and IMO
we should not promote it to *any* authoritative value. We should treat
it as if no Last-Modified header was sent at all.
Also, since we're talking about CGI here (which IIUC is an
implementation detail as far as HTTP is concerned), 7.1.1.1 has this to say:
Note: HTTP requirements for the date/time stamp format apply only
to their usage within the protocol stream. Implementations are
not required to use these formats for user presentation, request
logging, etc.
CGI communication is not part of the protocol stream. As long as we
don't run afoul of any CGI-related RFCs that lock us into a specific
interpretation of junk header data, 723x appears (to me) to have no
prohibition on fixing up or removing bad HTTP-dates coming from an
internal CGI backend. It's up to us to determine what is most
correct/useful behavior. (The situation might be different if we were
talking about a cache or a proxy, but we're not.)
Am I missing any relevant sections here?
(Unfortunately I won't be able to continue my part of the conversation
next week since I'll be out of the office; hopefully others will put in
their two cents.)
--Jacob
