Repository navigation
setcookie has an obsolete expires date format #9200
Description
Description
setcookie() gives an expires date format that is non-standard as per MDN and HTTP RFC 2616 - the latter of which explicitly refers to the format PHP's setcookie() outputs as "obsolete".
The following code:
<?php
setcookie('expires-format-test', 'test', strtotime('now + 1 minute'));Resulted in this header output:
Set-Cookie | expires-format-test=test; expires=Sat, 30-Jul-2022 05:12:54 GMT; Max-Age=60
But I expected this header output instead:
Set-Cookie | expires-format-test=test; expires=Sat, 30 Jul 2022 05:12:54 GMT; Max-Age=60
PHP Version
PHP 8.0.21
Operating System
No response
Activity
cmb69 commentedon Jul 30, 2022
The recently approved RFC 9110 states:
So while PHP does not comply to the RFC, it shouldn't cause issues. And given that the RFC 850 format is obsolete for a long time, I don't see the urgent need to fix this; i.e. I'd leave it for PHP 8.0 and 8.1 for BC reasons.
ChloeSartorelli commentedon Jul 30, 2022
If the format doesn't cause problems regardless of the format then I don't see how BC comes into it, but by the same token if it doesn't cause problems then it's fine to leave as is.
It would be nice if PHP used the "preferred" format as stated in the RFC but it seems unlikely the obsolete format will cause any problems for many years to come.
cmb69 commentedon Jul 30, 2022
I was mostly thinking about test expectations (at least some PHPTs in php-src would be affected).
TimWolla commentedon Jul 30, 2022
I agree here, this is not urgent to fix. The date parsing algorithm is explicitly defined in RFC 6265 (“Cookie RFC”), section 5.1.1 and it supports this legacy format (and various other questionable formats).
I agree with that, this is not something to backport into existing releases.
I'd like to see this fixed for PHP 8.2, though. Anything compatible with 2011 RFC 6265 will understand both formats and we should not try to attempt compatibility with more than a decade old systems if we're technically in violation of the spec.
TimWolla commentedon Jul 30, 2022
This also affects ext/date's DATE_FORMAT_COOKIE.
cmb69 commentedon Jul 30, 2022
And also the session cookie. Grepping for
D, d-M-Y H:i:s Tfinds these occurrences (there should be only one);DATE_FORMAT_COOKIEusesl, d-M-Y H:i:s T, though. I'm not sure that we should changeDATE_FORMAT_COOKIE; maybe it's better to introduce a new constant for this.TimWolla commentedon Jul 30, 2022
Ugh, indeed, full day-of-week name instead of abbreviation.
The correct format is already available as
DATE_RFC7231. It might be sense to simply refer to that constant in all the other locations. The explicit\G\M\Tis required,Tis incorrect.ChloeSartorelli commentedon Jul 31, 2022
Should everywhere that uses (or as we're discussing, should use) the
DATE_RFC7231format use that constant?derickr commentedon Aug 10, 2022
Nobody has reported that the current format causes any problems, and until somebody does, I am not in favour of changing this.
cmb69 commentedon Aug 10, 2022
The date format we're talking about has been introduced by RFC 850, which has been obsoleted by RFC 1036 in 1987! Furthermore, the format
30-Jul-2022makes no sense; nobody would write it that way. While I still don't see an urgent need to switch to a non obsolete format, I wouldn't want to keep it forever.Fixed phpGH-9200: setcookie has an obsolete expires date format
Update expires format for session cookie
Update expires format for session cookie (#9304)