Hi Chris,
I guess I figured if the parse failed the cal.set wouldn't happen.
Still, no harm in moving the 1970 into the loop on the off chance
something else goes wrong.
I've updated the test too. Thanks for spotting that.
-Rob
On 10/12/12 16:59, Chris Hegarty wrote:
Shouldn't 'cal.set(1970, 0, 1, 0, 0, 0)' be inside the for loop?
The test can simply throw Exception, rather can catching.
Otherwise, looks fine to me.
-Crhis.
On 06/12/2012 21:19, Rob McKenna wrote:
Hi folks,
According to HttpCookie.java:
"""
There are 3 http cookie specifications:
Netscape draft
RFC 2109 -/http://www.ietf.org/rfc/rfc2109.txt/
RFC 2965 -/http://www.ietf.org/rfc/rfc2965.txt/
HttpCookie class can accept all these 3 forms of syntax.
"""
According to http://www.ietf.org/rfc/rfc2109.txt section 10.1.2:
"""
Netscape's original proposal defined an Expires header that took a date
value in a fixed-length variant format in place of Max-Age: Wdy,
DD-Mon-YY HH:MM:SS GMT
"""
Thats in the "Historical" section provided to allow for compatibility
with Netscape's implementation, which we also support: (as per
http://docs.oracle.com/javase/6/docs/api/java/net/HttpCookie.html )
While we don't support the rfc explicitly, this change follows the
format specified in section 5.1.1 of rfc 6265:
"""
3. If the year-value is greater than or equal to 70 and less than or
equal to 99, increment the year-value by 1900.
4. If the year-value is greater than or equal to 0 and less than or
equal to 69, increment the year-value by 2000.
1. NOTE: Some existing user agents interpret two-digit years
differently.
"""
The webrev is at:
http://cr.openjdk.java.net/~robm/8000525/webrev.01/
<http://cr.openjdk.java.net/%7Erobm/8000525/webrev.01/>
Note: The addition of setLenient(false) has required changes to two
existing testcases.
-Rob
