Hiya Joe
I realise that the cookies themselves may not be compliant, either
because of bad JS or buggy clients, but CGI.pm manages to parse all of
the examples below, in the same way that browsers try to cope with dodgy
HTML. It'd be nice if libapreq were a bit more DWIM.
apreq is
- Original Message
From: Clinton Gormley cl...@traveljury.com
To: apreq-dev@httpd.apache.org
Sent: Saturday, February 14, 2009 8:21:51 AM
Subject: Cookie parsing errors: conflicting information, expected token not
present
[...]
I realise that the cookies themselves may not be
If you think CGI::Cookie (which is what CGI.pm uses) parses these cookies
correctly, you really haven't looked carefully enough. The only thing
CGI::Cookie does differently from libapreq2 is that it doesn't throw errors
on stuff it doesn't understand. Whether that's a bug or a feature is
Tell you what I'll do- I'll throw the cookie headers you mentioned earlier
into the test suite and see if I can adjust the parser to make better sense
of them (no promises tho). What won't change is the error behavior- apreq
will throw an error on invalid cookie headers, to alert you that
Steve Hay wrote:
Randy Kobes wrote:
Issac Goldstand wrote:
Steve Hay wrote:
Issac Goldstand wrote:
Vote results show only 2 +1s (issac,joes) and no -1s.
We're still a +1 short of release.
creating mod_apreq2.la
(cd .libs rm -f mod_apreq2.la ln -s ../mod_apreq2.la mod_apreq2.la)
make:
Philip M. Gollucci wrote:
Steve Hay wrote:
Randy Kobes wrote:
Issac Goldstand wrote:
Steve Hay wrote:
Issac Goldstand wrote:
Vote results show only 2 +1s (issac,joes) and no -1s.
We're still a +1 short of release.
creating mod_apreq2.la
(cd .libs rm -f mod_apreq2.la ln -s
