Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: HttpCookie
    • Labels:
      None

      Description

      Seeing this very often:

      Invalid cookie header: "Set-Cookie: _asid=011e7014f5e7718e02d893335aa5a16e; path=/; expires=Wed, 16 May 2018 17:13:32 GMT". Unable to parse expires attribute: Wed, 16 May 2018 17:13:32 GMT

        Issue Links

          Activity

          Oleg Kalnichevski made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Mark Thomas made changes -
          Workflow jira [ 12580928 ] Default workflow, editable Closed status [ 12606753 ]
          Mark Thomas made changes -
          Workflow Default workflow, editable Closed status [ 12558111 ] jira [ 12580928 ]
          Mark Thomas made changes -
          Workflow jira [ 12483653 ] Default workflow, editable Closed status [ 12558111 ]
          Hide
          Jörgen Rydenius added a comment -

          Separate issue opened as HTTPCLIENT-923.

          Show
          Jörgen Rydenius added a comment - Separate issue opened as HTTPCLIENT-923 .
          Hide
          Oleg Kalnichevski added a comment -

          Jörgen,

          Please open a separate issue for this change request.

          Oleg

          Show
          Oleg Kalnichevski added a comment - Jörgen, Please open a separate issue for this change request. Oleg
          Hide
          Jörgen Rydenius added a comment -

          Oleg, you are correct that the Netscape Draft specification (http://curl.haxx.se/rfc/cookie_spec.html) specifies clearly that the date format is "Wdy, DD-Mon-YYYY HH:MM:SS GMT". But on the other hand, in the examples section of the same document, the only example header that contains "Expires" is the following:

          Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT

          Note that the weekday is fully spelled out and that the year is written as two digits only. I would say that the specification therefore makes the 2 or 4 digit year optional. I think NetscapeDraftSpec should reflect this. An example of a product that uses the 2 digit version is jetty. When using httpclient 4 talking to a jetty server, any Set-Cookie headers for persistent cookies will be interpreted as a 4 digit year in the date and the cookie will immediately be disregarded as expired by some 2,000 years or so. Httpclient 3 on the other hand had no problem understanding the persistent cookies from jetty. I filed a bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=304698 on jetty to change their date format, but on the other hand I also think httpclient 4 is too strict about the date format when even the original specification uses two alternatives.

          Workaround is easy by setting CookieSpecPNames.DATE_PATTERNS, but I really think that products like jetty and httpclient should be compatible by default. Also, since the date format used by jetty is parsable but misinterpreted and disregarded by httpclient makes it especially hard to detect the first time on encounters the problem.

          Show
          Jörgen Rydenius added a comment - Oleg, you are correct that the Netscape Draft specification ( http://curl.haxx.se/rfc/cookie_spec.html ) specifies clearly that the date format is "Wdy, DD-Mon-YYYY HH:MM:SS GMT". But on the other hand, in the examples section of the same document, the only example header that contains "Expires" is the following: Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT Note that the weekday is fully spelled out and that the year is written as two digits only. I would say that the specification therefore makes the 2 or 4 digit year optional. I think NetscapeDraftSpec should reflect this. An example of a product that uses the 2 digit version is jetty. When using httpclient 4 talking to a jetty server, any Set-Cookie headers for persistent cookies will be interpreted as a 4 digit year in the date and the cookie will immediately be disregarded as expired by some 2,000 years or so. Httpclient 3 on the other hand had no problem understanding the persistent cookies from jetty. I filed a bug report https://bugs.eclipse.org/bugs/show_bug.cgi?id=304698 on jetty to change their date format, but on the other hand I also think httpclient 4 is too strict about the date format when even the original specification uses two alternatives. Workaround is easy by setting CookieSpecPNames.DATE_PATTERNS, but I really think that products like jetty and httpclient should be compatible by default. Also, since the date format used by jetty is parsable but misinterpreted and disregarded by httpclient makes it especially hard to detect the first time on encounters the problem.
          Hide
          Fuad Efendi added a comment - - edited

          The only difference is comma after day of week...

          Thank you very much Oleg!

          So, it is configurable, nothing to fix.

          Show
          Fuad Efendi added a comment - - edited The only difference is comma after day of week... Thank you very much Oleg! So, it is configurable, nothing to fix.
          Oleg Kalnichevski made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Won't Fix [ 2 ]
          Hide
          Oleg Kalnichevski added a comment -

          The format of the cookie in question is compatible with the Netscape Draft specification only. The best match cookie policy correctly identifies the cookie as Netscape but parsing of the 'expires' attribute fails because the only date format permitted by the Netscape Draft is "EEE, dd MMM-yyyy-HH:mm:ss z". In order to make HttpClient accept cookies containing nonstandard 'expires' one should set valid date formats using 'http.protocol.cookie-datepatterns' parameter. See example:


          BasicHttpParams params = new BasicHttpParams();
          params.setParameter(CookieSpecPNames.DATE_PATTERNS,
          Arrays.asList("EEE, dd MMM-yyyy-HH:mm:ss z", "EEE, dd MMM yyyy HH:mm:ss z"));
          BestMatchSpecFactory factory = new BestMatchSpecFactory();
          CookieSpec cookiespec = factory.newInstance(params);
          BasicHeader header = new BasicHeader("Set-Cookie",
          "asid=011e7014f5e7718e02d893335aa5a16e; path=/; " +
          "expires=Wed, 16 May 2018 17:13:32 GMT");
          CookieOrigin origin = new CookieOrigin("localhost", 80, "/", false);
          List<Cookie> cookies = cookiespec.parse(header, origin);
          System.out.println(cookies);


          I guess the policy was made stricter sometime post 4.0-beta1

          Hope this clarifies the situation somewhat

          Oleg

          Show
          Oleg Kalnichevski added a comment - The format of the cookie in question is compatible with the Netscape Draft specification only. The best match cookie policy correctly identifies the cookie as Netscape but parsing of the 'expires' attribute fails because the only date format permitted by the Netscape Draft is "EEE, dd MMM-yyyy-HH:mm:ss z". In order to make HttpClient accept cookies containing nonstandard 'expires' one should set valid date formats using 'http.protocol.cookie-datepatterns' parameter. See example: BasicHttpParams params = new BasicHttpParams(); params.setParameter(CookieSpecPNames.DATE_PATTERNS, Arrays.asList("EEE, dd MMM-yyyy-HH:mm:ss z", "EEE, dd MMM yyyy HH:mm:ss z")); BestMatchSpecFactory factory = new BestMatchSpecFactory(); CookieSpec cookiespec = factory.newInstance(params); BasicHeader header = new BasicHeader("Set-Cookie", "asid=011e7014f5e7718e02d893335aa5a16e; path=/; " + "expires=Wed, 16 May 2018 17:13:32 GMT"); CookieOrigin origin = new CookieOrigin("localhost", 80, "/", false); List<Cookie> cookies = cookiespec.parse(header, origin); System.out.println(cookies); I guess the policy was made stricter sometime post 4.0-beta1 Hope this clarifies the situation somewhat Oleg
          Hide
          Fuad Efendi added a comment -

          I still see this problem in version 4.0 (loaded by Maven from Maven repository).

          And I don't see this problem with version 4.0-beta3-SNAPSHOT (loaded by Maven from Apache repository).

          09/12/02 21:01:31 WARN protocol.ResponseProcessCookies: Invalid cookie header: "Set-cookie: session-id-time=1260345600l; path=/; domain=.amazon.com; expires=Wed
          Dec 09 08:00:00 2009 GMT". Unable to parse expires attribute: Wed Dec 09 08:00:00 2009 GMT
          09/12/02 21:01:31 WARN protocol.ResponseProcessCookies: Invalid cookie header: "Set-cookie: session-id=192-5799048-2819311; path=/; domain=.amazon.com; expires=
          Wed Dec 09 08:00:00 2009 GMT". Unable to parse expires attribute: Wed Dec 09 08:00:00 2009 GMT

          Show
          Fuad Efendi added a comment - I still see this problem in version 4.0 (loaded by Maven from Maven repository). And I don't see this problem with version 4.0-beta3-SNAPSHOT (loaded by Maven from Apache repository). 09/12/02 21:01:31 WARN protocol.ResponseProcessCookies: Invalid cookie header: "Set-cookie: session-id-time=1260345600l; path=/; domain=.amazon.com; expires=Wed Dec 09 08:00:00 2009 GMT". Unable to parse expires attribute: Wed Dec 09 08:00:00 2009 GMT 09/12/02 21:01:31 WARN protocol.ResponseProcessCookies: Invalid cookie header: "Set-cookie: session-id=192-5799048-2819311; path=/; domain=.amazon.com; expires= Wed Dec 09 08:00:00 2009 GMT". Unable to parse expires attribute: Wed Dec 09 08:00:00 2009 GMT
          Fuad Efendi made changes -
          Field Original Value New Value
          Link This issue is a clone of HTTPCLIENT-773 [ HTTPCLIENT-773 ]
          Fuad Efendi created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Fuad Efendi
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development