The WebClient will disregard a server's Set-Cookie header and not set a cookie if the server's hostname lacks a '.' character (i.e., is not fully qualified) and is neither equal to 'localhost' nor equal to HtmlUnitBrowserCompatCookieSpec.LOCAL_FILESYSTEM_DOMAIN. This can cause uses of WebClient that depend on cookies to fail on typical development environments, where the hostname may be an unqualified local name.
This behavior appears to originate in HtmlUnitDomainHandler, and there is no apparent straightforward means of overriding it, since the use of HtmlUnitBrowserCompatCookieSpec is assumed throughout WebClient and HttpWebConnection.
This behavior does not occur prior to HtmlUnit 2.16. Attached are two patches that demonstrate this: One for HtmlUnit 2.15, which does not reproduce the issue; and another for HtmlUnit 2.16 and up (including trunk), which does reproduce the issue. Please note the comment in the patch indicating necessary adjustments to /etc/hosts.
(Adding second attachment)
Hi Jacob,
Can you provide a patch for a test case that extends WebDriverTestCase, e.g. similar to CookieManagerTest?
So we can verify the behavior against real browsers as well.
Okay, I'm not too familiar with WebDriver usage, but here is a version of the test that extends WebDriverTestCase. I've run it against the 2.15 branch, the 2.17 branch, and trunk; as with the earlier patch, it fails on 2.17 and trunk, but not 2.15.
Fixed in SVN, thanks a lot for reporting, and for the test case.
Please always try to use the trunk or latest released version, as we don't support earlier ones.