[
https://issues.apache.org/jira/browse/HTTPCLIENT-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018753#comment-13018753
]
Andreas Fagschlunger commented on HTTPCLIENT-1077:
--------------------------------------------------
Please see section "10.1.2 Expires and Max-Age" of the RFC 2109:
http://www.ietf.org/rfc/rfc2109.txt
{code}
10.1.2 Expires and Max-Age
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
Note that the Expires date format contains embedded spaces, and that
"old" cookies did not have quotes around values. Clients that
implement to this specification should be aware of "old" cookies and
Expires.
{/code}
According to the Specification the HttpClient should be able to handle "old"
cookies without quotes when CookiePolicy.RFC2109 is explicitly set? Or am I
wrong? Please also note that HttpClient 3.1 was able to handle such Cookies.
> CookiePolicy.RFC_2109: Unable to parse expires attribute (Thu, 01-Dec-94
> 16:00:00 GMT)
> --------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1077
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1077
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpCookie
> Affects Versions: 4.1.1
> Environment: JVM where de default Locale ist not Locale.US.
> Reporter: Andreas Fagschlunger
> Priority: Minor
> Labels: coocki
> Attachments: HTTPCLIENT-1077.zip
>
>
> In our Application we're facing problems using HttpClient 4.x (didn't have
> that problem with HttpClient 3.1). The HttpClient has problems parsing the
> Cookie's Expires-Attribute:
> 2011-04-08 10:14:21,647 [btpool0-0] WARN
> org.apache.http.client.protocol.ResponseProcessCookies - Invalid cookie
> header: "Set-Cookie: dfName=""; Expires=Thu, 01-Dec-94 16:00:00 GMT;
> Path=/appl/ebp". Unable to parse expires attribute: Thu
> We are using Cookie-Policy RFC2109:
> httpClient = new DefaultHttpClient(connectionManager);
> httpClient.getParams().setParameter(ClientPNames.COOKIE_POLICY,
> CookiePolicy.RFC_2109);
> The problems seems to be the JVM's default Locale, which is in our case de_AT
> and not en_US. See following Example:
> [Java]
> System.out.println("Locale=" + Locale.getDefault());
> String[] datePatterns = new String[] {
> DateUtils.PATTERN_ASCTIME,
> DateUtils.PATTERN_RFC1036,
> DateUtils.PATTERN_RFC1123 };
> for (String pattern : datePatterns) {
> try {
> SimpleDateFormat dateFormat = new SimpleDateFormat(pattern);
> dateFormat.parse("Thu, 01-Dec-94 16:00:00 GMT");
> } catch (ParseException e) {
> System.out.println("Pattern '" + pattern + "' failed.");
> }
> }
> [/Java]
> The output for me is following:
> Locale=de_AT
> Pattern 'EEE MMM d HH:mm:ss yyyy' failed.
> Pattern 'EEEE, dd-MMM-yy HH:mm:ss zzz' failed.
> Pattern 'EEE, dd MMM yyyy HH:mm:ss zzz' failed.
> Setting the default Locale to US (Locale.setDefault(Locale.US)), the output
> changes:
> Locale=en_US
> Pattern 'EEE MMM d HH:mm:ss yyyy' failed.
> Pattern 'EEE, dd MMM yyyy HH:mm:ss zzz' failed.
> So the Date (Thu, 01-Dec-94 16:00:00 GMT) and the pattern
> (DateUtils.PATTERN_RFC1036: EEEE, dd-MMM-yy HH:mm:ss zzz) seem to be valid,
> just the Locale is not explicitly set for the SimpleDateFormat:
> http://download.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html#SimpleDateFormat%28java.lang.String,%20java.util.Locale%29
> I hope I didn't waste your time and this is realy a bug.
> Best regards,
> Billie
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
