Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#382 HttpOnly cookie looses all cookie info

closed-rejected
Wolfgang Fahl
None
5
2008-03-31
2007-03-02
tiblu
No

The cookie is set like that:
"Set-Cookie: myStuff=1234; path=/foo; HttpOnly"

Now, when HttpUnit sees something like that, it just drops all cookies and does not get anything.

When change the end of the Set-Cookie to "HttpOnly=", it works just fine. But I'm not sure if browser (IE) will follow the directive and if I can make this change to the web application.

RESOLUTION:
Janno from workplace did following:
in RFC2109CookieRecipe class defined in CookieJar added "httponly" to isCookieReservedWord().

So the source:

class RFC2109CookieRecipe extends CookieRecipe {

protected boolean isCookieAttribute( String stringLowercase ) {
return stringLowercase.equals("path") ||
stringLowercase.equals("domain") ||
stringLowercase.equals("expires") ||
stringLowercase.equals("comment") ||
stringLowercase.equals("max-age") ||
stringLowercase.equals("version");
}

protected boolean isCookieReservedWord( String token ) {
return token.equalsIgnoreCase( "secure" ) || token.equalsIgnoreCase( "httponly" );
}
}

If this is the right way to do it, someone commit to CVS.

Discussion

  • Wolfgang Fahl
    Wolfgang Fahl
    2008-03-31

    Logged In: YES
    user_id=1220573
    Originator: NO

    Dear httpunit user!

    Thank you for your bug report. We appreciate the time and effort you are putting into this.

    Please supply a testcase with the expected result for the bug report that you are asking a solution for and we'll look into implementing it. For a start you might want to get the trunk version from the subversion repository (see https://sourceforge.net/svn/?group_id=6550\)
    and have a look at the source code of some of the more than 700 JUnit based testcase in there.
    This should give you a clue on what a proper testcase for httpunit looks like.

    When you are ready you might want to attach the testcase (and if you already have started implementing a solution for it it also the actual code) to the patch section of the sourceforge.net tracker for patches of the httpunit project at
    https://sourceforge.net/tracker/?atid=306550&group_id=6550&func=browse.

    The main communication about further details of the development is via the httpunit developer mailinglist. You are most welcome to sign up via
    https://lists.sourceforge.net/lists/listinfo/httpunit-develop

    Yours
    The httpunit developer team

    (Russell and Wolfgang as of 2008-03)

     
  • Wolfgang Fahl
    Wolfgang Fahl
    2008-03-31

    • assigned_to: nobody --> wolfgang_fahl
    • status: open --> closed-rejected
     
  • Wolfgang Fahl
    Wolfgang Fahl
    2008-03-31

    Logged In: YES
    user_id=1220573
    Originator: NO

    I've tried this and it works:

    /**
    * test for bug report [ 1672385 ] HttpOnly cookie looses all cookie info
    * @throws Exception
    */
    public void testHttpOnlyCookies() throws Exception {
    CookieJar jar = new CookieJar(
    new TestSource( new URL( "http://www.meterware.com" ),
    new String[] { "myStuff=1234; path=/foo; HttpOnly"} ) );
    assertEquals( "cookie 'myStuff' value", "1234", jar.getCookieValue( "myStuff" ) );
    }

     
  • Nagaraj Mandya
    Nagaraj Mandya
    2010-04-22

    This bug is not closed. While the cookie can still be retrieved, the path is messed up. Using your example itself, try getting the path of the cookie.

    CookieJar jar = new CookieJar(
    new TestSource( new URL( "http://www.meterware.com" ),
    new String[] { "myStuff=1234; path=/foo; HttpOnly"} ) );
    System.out.println(jar.getCookie("myStuff").getPath());

    This will display "/foo,HttpOnly" instead of just "/foo". The problem is that on subsequent requests to any resource under the /foo path, the cookie does not get sent to the server because the path does not match.

     
  • Melloware Inc
    Melloware Inc
    2012-06-12

    I just pulled the latest /trunk and compiled and it seems to have fixed it. Is this version ever going to get released on Maven Central?