httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <>
Subject Re: svn commit: r1750953 - /httpd/httpd/trunk/server/util_script.c
Date Sat, 23 Jul 2016 08:12:37 GMT
2016-07-23 1:18 GMT+02:00 Jacob Champion <>:

> 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), 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.)
First of all thanks all for the good discussion, I am going to add my two
cents. So I can see two relevant and separate changes:

1) Any invalid value like "Last-Modified: foo" (that generates a
APR_DATE_BAD from APR) should be considered bogus and dropped, leaving a
meaningful trace for the admin. This would be great in my opinion since
httpd should be a "safe net" for honest mistakes made by backend developers
that might accidentally introduce bogus headers like this one. I am not
seeing any good use case that would legitimate turning a value like "foo"
into a valid GMT datetime.

2) Interpreting header values not strictly allowed turning them into a
valid GMT datetime value would be a good feature for httpd and something
that our users will like (as stated for example by the person that brought
up this issue on users@), but we need of course to consider the RFCs first.
As Jacob pointed out I don't see any piece of the 723x RFCs stating clearly
that the new proposed behavior is wrong, but I also value a lot William's
experience in dealing with RFCs so it might be good to re-think the patch
to something less intrusive like This patch would
be a compromise between my initial proposal and Yann's.


PHP script returning Last-Modified: Sat, 23 Jul 2016 10:00:27 +0200
GMT now: Sat, 23 Jul 2016 08:00:27 GMT

Header returned by httpd: Last-Modified: Sat, 23 Jul 2016 08:00:27 GMT

util_script.c(564): [client ::1:44380]   Last-Modified: Sat, 23 Jul 2016
10:00:27 +0200
util_script.c(683): [client ::1:44380] The Last-Modified header value 'Sat,
23 Jul 2016 10:00:27 +0200' (in the future considering the GMT timezone)
has been replaced with 'Sat, 23 Jul 2016 08:00:27 GMT'
http_filters.c(835): [client ::1:44380]   Last-Modified: Sat, 23 Jul 2016
08:00:27 GMT

The wording could be different of course, I am a non native english speaker
so please let me know if there is anything better than these messages.

Caveat: any httpd processing time would be added to the final Last-Modified
value, something that confused a lot the person that brought up this issue
on users@ (original repro case from users@:

I am happy with any solution that we choose, as long as we reach a final
and shared agreement without getting stuck for too long (with the risk of
adding dust and dropping this change completely).



View raw message