#85 closed defect (invalid)
ngx_http_cookie_time date format error.
| Reported by: | www.google.com/accounts/o8/id?id=AItOawlrxMzFiqtYmFkACG7ogDCuySTFNsYFYlw | Owned by: | somebody |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-core | Version: | 1.0.x |
| Keywords: | Cc: | ||
| uname -a: | Linux ubuntu 2.6.32-32-generic #62-Ubuntu SMP Wed Apr 20 21:52:38 UTC 2011 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.0.11
TLS SNI support enabled configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/nginx-development-kit --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/nginx-upstream-fair --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/nginx-echo --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/nginx-lua --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/nginx-http-push --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/nginx-upload-progress --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/headers-more-nginx-module --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/chunkin-nginx-module --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/encrypted-session-nginx-module --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/ngx_http_upstream_keepalive --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/set-misc-nginx-module --add-module=/vagrant/nginx/nginx-1.0/nginx-1.0.11/debian/modules/srcache-nginx-module |
||
Description
This function returns date which is not RFC complaint. For example chrome browser doesn't understand expire which is set to "Wed, 11-Jan-12 14:27:12 GMT".
According to RFC date should be "Wdy, DD-Mon-YYYY HH:MM:SS GMT"
Change History (7)
comment:1 by , 12 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:2 by , 12 years ago
Actually it occurred that google chrome simply doesn't save cookies for domain=localhost only for registry controlled domains. Thus it's not defect I think...
comment:4 by , 5 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
RFC 6265 says "To avoid compatibility issues, servers SHOULD use the rfc1123-date format, which requires a four-digit year". There is no earthly reason in this day and age to deliberately use a 2-digit year - a format which was obsolete decades before the first version of nginx was ever released and which has never been correct in Set-Cookie headers. If that doesn't convince you, should nginx not be sticking to "conservative in what you send"? It is almost unheard of for software to use 2-digit dates in the modern era.
comment:5 by , 5 years ago
| Resolution: | → invalid |
|---|---|
| Status: | reopened → closed |
As outlined above, when the code in question was written, there were at least some browsers in use which wasn't able to parse 4-digit years. Also, as outlined above, the format in question is correct for Set-Cookie headers, and expected to be understood by all standard-compliant clients.
While now it is probably safe enough to switch to using 4-digit years, since affected browsers are no longer widely used, there are no obvious reasons to do so. Currently used format is correct and not expected to cause any negative effects, except it can be understood by old browsers in question. If you think there are any issues caused by the format used, please provide specific examples.
comment:6 by , 5 years ago
I'm not sure why "the specification says you SHOULD NOT do this" isn't good enough to make a change that would be trivial to implement and would bring nginx in line with pretty much every other piece of web software. But if you insist on breaking the spec then obviously I can't stop you.
comment:7 by , 5 years ago
The "SHOULD NOT" is not the same as "MUST NOT", and not following a "SHOULD NOT" clause doesn't mean "breaking the spec". It is defined as follows:
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
Support for the browsers in question clearly was a serious enough reason to use 2-digit years at the time the code was written, and we haven't seen any negative implications since then. Further, given that we automatically switch to 4-digit years after 2037, I won't expect any possible implications outlined in RFC 6265 to apply.
As previously suggested, if you think that there are any negative implications we've missed, please provide specific examples.
Claim that Chrome can't parse time in question isn't true, it parses the expires time in question without problems (and the code says the same).
While referenced specification is indeed suggests 4-digit years, you may notice 2-digit year in examples given. And this is because it originally had 2-digit year. There is at least one reason to use 2-digit years, as outlined in the code of the function in question: there are browsers which can't parse 4-digit ones.
Most current standard to follow is probably RFC6265, and it states that 2-digit years as produced by nginx should be parsed by all complaint browsers. See http://tools.ietf.org/html/rfc6265#section-5.1.1 for details.