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 <e...@agharta.de> wrote:
> On Wed, Sep 30, 2009 at 5:35 PM, Andrei Stebakov <lisper...@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.
>
_______________________________________________
drakma-devel mailing list
drakma-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
