Hello list, The current version of Drakma contains a check of cookie domains' validity. A (textual) domain is considered to be valid iff either it contains a dot or is exactly "localhost". I'm sure there is a reason for this (perhaps some part of a relevant RFC?), but I got bitten by it in a real-world scenario. I was using Drakma for testing of a Java EE-based web application at my company, accessible at the internal address "http://someserver:9090/gui/app". The relevant headers returned are: DRAKMA> (http-request "http://someserver:9090/gui/app") ==> "blah blah blah, some HTML" 200 ((:X-POWERED-BY . "Servlet/2.5") (:SERVER . "Sun Java System Application Server 9.1") (:SET-COOKIE . "JSESSIONID=41165991cdf70add1d9e0a103cfc; Path=/gui") (:CONTENT-TYPE . "text/html;charset=UTF-8") (:DATE . "Tue, 15 Jul 2008 00:14:24 GMT") (:CONNECTION . "close")) #<URI http://someserver:9090/gui/app> #<FLEXI-STREAMS::FLEXI-UTF-8-IO-STREAM {BB78A59}> T "OK" and if I pass a cookie jar to such HTTP-REQUEST, the returned cookie is not included in the jar due to the checking machinery. FWIW, Firefox 3 does include it (and so the app works on Firefox 3, but fails the Drakma tests). I quickly hacked up a patch (attached) to Drakma which adds a special variable *ALLOW-DOTLESS-COOKIE-DOMAINS-P*, which, when set to non-NIL, causes the domains like SOMESERVER to be accepted. Might it be useful to include in the official distribution? Best regards, -- Daniel Janus <daniel@sentivision.com> Quality Assurance Specialist, SENTIVISION Mb: +48 501 180 396 | Ph: +48 22 640 0860