[drakma-devel] drakma:get-cookies fails to parse cookies with commas in values

[Andrei Stebakov]

Looks like according to RFC 2109, "=" takes priority over "," so probably
when we encounter something like session=foo,bar=baz, the parser should
analyze sequences on both sides of an "=" character, so in this case comma
becomes a separator of two different pairs.

On Wed, Sep 30, 2009 at 10:41 AM, Edi Weitz <edi at agharta.de> wrote:

> On Wed, Sep 30, 2009 at 11:09 AM, Edi Weitz <edi at 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/drakma-devel/attachments/20090930/041909ba/attachment.html>