From:             ceefour at gauldong dot net
Operating system: Apache/1.3.33 (Unix) mod_ssl/2.8
PHP version:      4.3.10
PHP Bug Type:     Date/time related
Bug description:  date('r') & gmdate('r') incorrect when used with 
header('Last-Modified:')

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

-- 
Edit bug report at http://bugs.php.net/?id=31842&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=31842&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=31842&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=31842&r=trysnapshot51
Fixed in CVS:                http://bugs.php.net/fix.php?id=31842&r=fixedcvs
Fixed in release:            http://bugs.php.net/fix.php?id=31842&r=alreadyfixed
Need backtrace:              http://bugs.php.net/fix.php?id=31842&r=needtrace
Need Reproduce Script:       http://bugs.php.net/fix.php?id=31842&r=needscript
Try newer version:           http://bugs.php.net/fix.php?id=31842&r=oldversion
Not developer issue:         http://bugs.php.net/fix.php?id=31842&r=support
Expected behavior:           http://bugs.php.net/fix.php?id=31842&r=notwrong
Not enough info:             
http://bugs.php.net/fix.php?id=31842&r=notenoughinfo
Submitted twice:             
http://bugs.php.net/fix.php?id=31842&r=submittedtwice
register_globals:            http://bugs.php.net/fix.php?id=31842&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=31842&r=php3
Daylight Savings:            http://bugs.php.net/fix.php?id=31842&r=dst
IIS Stability:               http://bugs.php.net/fix.php?id=31842&r=isapi
Install GNU Sed:             http://bugs.php.net/fix.php?id=31842&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=31842&r=float
No Zend Extensions:          http://bugs.php.net/fix.php?id=31842&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=31842&r=mysqlcfg

Reply via email to