I think those are two different issues we are taking about.
In your case, yes, most likely bar=baz makes a new cookie (according to the RFC).
In my case "session=6,Direct,placeholder,test.com;" is an obvious attribute-value pair followed by a ";". (as per RFC: "av-pairs = av-pair *(";" av-pair)" )
What I am trying to say that drakma shouldn't stumble upon the comma after "6", since the next construct is not "name=value", but only a token.
I agree, that they break a rule set by the RFC 2068, which defines a token as
    token          = 1*<any CHAR except CTLs or tspecials>
where
    tspecials      = "(" | ")" | "<" | ">" | "@"
                         | "," | ";" | ":" | "\" | <">
                         | "/" | "[" | "]" | "?" | "="
                         | "{" | "}" | SP | HT

So, having a comma in a token "6,Direct,placeholder,test.com" is against the rule but in this case it's still easily identifiable as value for the "session=6,Direct,placeholder,test.com;" av-pair so it needs to be fixed or some api provided so this issue could be overcome.

Thank you,
Andrei

On Wed, Sep 30, 2009 at 5:58 PM, Edi Weitz <edi@agharta.de> wrote:

On Wed, Sep 30, 2009 at 5:35 PM, Andrei Stebakov <lispercat@gmail.com> wrote:
> 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.

Ah, that's something I've been missing so far. Can you point to where
exactly this can be found in the RFC? That should make the cookie
parsing code clearer and I should be able to get rid of the comma
workaround which is already in there.

Thanks,
Edi.