On Wed, Sep 30, 2009 at 11:09 AM, Edi Weitz <e...@agharta.de> wrote: > I was going to write that IIS sends a wrong header according to the > RFCs, but after re-reading them I now think that one might interpret > them in a different way and that Drakma's general handling of commas > has to be reworked to accommodate this interpretation.
No. In the meantime, I think this cookie really looks fishy. In RFC 2109 (for "Set-Cookie") the syntax is defined as "1#cookie" which according to the HTTP specification this RFC refers to means a comma-separated list of values, i.e. if a comma is not quoted, it separates one Set-Cookie header from the next one. I understand that this is kind of sloppy already because lots of servers use a syntax were the date in "expires" uses a comma in the wrong place and Drakma caters to that. The question is how to deal with commas in general. Consider this example: Set-Cookie: domain=test.com; expires=Thu, 12-Sep-2109 14:58:04 GMT; session=foo,bar=baz If sent by IIS this probably means (?) that the cookie "domain" has an attribute "session" with the value "foo,bar=baz", right? But it could also mean (see RFC) that the value of "session" is "foo" and that there's a second cookie "bar" with the value "baz". In fact, if Drakma reads two header lines like so Set-Cookie: domain=test.com; expires=Thu, 12-Sep-2109 14:58:04 GMT; session=foo Set-Cookie: bar=baz it will actually join them with a comma before parsing them (in accordance with the HTTP RFC). So, we could probably provide some special variable to make cookie parsing less restrictive, but I wonder what the exact semantics of this should be. Any suggestions? Thanks, Edi. _______________________________________________ drakma-devel mailing list drakma-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel