Opened 13 years ago

Closed 5 years ago

Last modified 5 years ago

#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"

http://curl.haxx.se/rfc/cookie_spec.html

Change History (7)

comment:1 by Maxim Dounin, 13 years ago

Resolution: invalid
Status: newclosed

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.

comment:2 by www.google.com/accounts/o8/id?id=AItOawlrxMzFiqtYmFkACG7ogDCuySTFNsYFYlw, 13 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:3 by Maxim Dounin, 5 years ago

See also #1828.

comment:4 by jribbens@…, 5 years ago

Resolution: invalid
Status: closedreopened

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 Maxim Dounin, 5 years ago

Resolution: invalid
Status: reopenedclosed

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 jribbens@…, 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 Maxim Dounin, 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.

Note: See TracTickets for help on using tickets.