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.