Description:
------------
date('r') and gmdate('r') outputs a formatted date/time string that is incompatible with header('Last-Modified'). I guess this is caused by incompatibility between the specs (HTTP/1.1, RFC 2616) and the format outputted by date('r')/gmdate('r'), which is in RFC 2822.

RFC 2616 and RFC 2822 uses VERY similar date format except for the fact RFC 2822 allows the day to be one digit while RFC 2616 doesn't (actually it does allow it but using a wholely different format).

I was sure that this is not a bug in the Apache 1.3.33 web server, since it should accept any "funny" Last-Modified header outputted by any CGI program or module including PHP.

When a date format in header('Last-Modified') is invalid, the actual header sent would be:

Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT

which is definitely NOT what we want. The page will always be cached by the browser and never updated, since it's assumed to never have modified.

My proposal for the resolution for this bug are BOTH of below:
1. Change the output of date('r')/gmdate('r') to be identical to date("D, d M Y H:i:s O"), which is conformant to both RFC 2822 and RFC 2616, and in addition accepted by header('Last-Modified'), and any web server out there which is too strictly RFC 2616 compliant and not RFC 2822 compliant (they aren't required to, but I think it's better to stay on the safe side).
2. Change behavior of header('Last-Modified') so it accepts any input. Or in case of invalid input it defaults of NOT outputting the Last-Modified header at all, or use the current system time in the local time (formatted as point number 1 above).

Anyway, I'm expecting a "date('r') is compliant with RFC 2822, so its behavior shouldn't be changed" response to this bug report. Yes, actually it is. But the use for this is common for outputting RFC 2616 dates (since they look VERY similar, the difference is very subtle yet fatal!)

Im my opinion, we should strive more for broadest compatibility rather than strict conformance to a particularly stated formal standard. My proposed change in behavior above, IMHO, does not change date('r')'s conformance to RFC 2822 (since RFC 2822 accepts 2-digit days anyway, no matter whether the day actually only needs 1 digit).

Reproduce code:
---------------
date('r');


Expected result:
----------------
Fri, 04 Feb 2005 08:55:05 +0000

Actual result:
--------------
Fri,  4 Feb 2005 08:55:05 +0000