On 08/01/2016 01:35 PM, William A Rowe Jr wrote:
> I do like your argument that we should do as little transformation
> as possible, in order to facilitate moving CGI apps between
> environments. Implementation differences are nasty for everyone. But
> I'm not convinced that ship hasn't sailed; currently, it looks like
> we modify outgoing CGI responses in order to merge headers,
> normalize Content-Type, and produce Unmodified and Precondition
> Failed responses.
Merging headers is a well-defined behavior in the HTTP spec (see my earlier
comments on RFC 3875). Three CGI header fields are CGI-specific. I don't
know that you can correlate these mandated adjustments to date formats.
I mean that we're merging CGI headers with other headers that have
already been defined by the server (whatever those are); the things
we've added would have to be replicated in other CGI environments
anyway. That's probably one of my weaker arguments though, and I'm okay
with dropping it.
The precondition check behavior still stands as another major
non-transparent treatment of a response. But there are outstanding bugs
on that behavior and, again, I'm not sure it's strong enough to stand
alone as an argument.
> > If there is date input that we cannot handle, the
> > spec strongly encourages us to interpret it as now(), provided
> > we have a
> > clock (which all of our architectures do.)
> In the absence of a quote from the spec, I'm still in strong
> disagreement with this, based on the language I quoted last week.
The spec demands future -> now() if we know now(). On other erroneous data,
that's up for debate.
Agreed (and see below).
> Moving on to Stefan's comments:
> > If we see CGI as a kind of input that is not strictly regulated by
> > HTTP header formats (and that is an if), we should correct timezone
> > offset to GMT, but otherwise leave the time unchanged. It might
> > be our clock that has the issue. Meddling with it will not help anyone
> > debugging problems.
> +1 (and I am currently of the opinion that CGI is not a strict HTTP
> input, as stated above).
Jacob and I have entirely different opinions on that, Stefan's comment
is very interesting. We have a clock on nearly every deployment of
httpd, but that doesn't mean it is correct. However the spec absolutely
demands that we do not send our untrusted "Date:" with a future
"Last-Modified:" value, it is externally inconsistent.
Ah, right. My +1 to Stefan needed the exception that we still need to
pull future values back; agreed.
So this alternative is not my first choice. Invalid headers should
really either be corrected (if the correction is obvious, safe, and
helpful), or dropped entirely. Or the entire response should be
500'd, but we run into major compatibility breaks if we choose that
route.
No, I agree that a 500 is not an option. Drop it, or fix it loudly in
the logs,
but we can't break existing deployments (which don't accept non-GMT
dates today, FWIW).
Based on conversations with Luca, existing deployments do "accept"
non-GMT dates, silently corrupting the value, due to the use of the
*_parse_http() function.
I'm happy to react to bad input following a parsable date string, e.g. any
non-"GMT" signifier, as entirely bad input worth emitting to the error log.
Let's help CGI authors find their bugs instead of generating unexpected
results, such as 5-8 hour wrong "Last Modified" dates in the US and
now() throughout Europe, owing to the time zone deltas.
Cool. I'm not opposed to loudly dropping non-GMT timestamps (though I
still prefer fixing them up).
Any other opinions? I've talked enough I think. :)
--Jacob
