Request for review: 8000525: Java.net.httpcookie api does not support 2-digit year format
rob.mckenna at oracle.com
Wed Dec 12 15:43:38 UTC 2012
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.
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.
> 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
>> The webrev is at:
>> Note: The addition of setLenient(false) has required changes to two
>> existing testcases.
More information about the core-libs-dev