----- Original Message ---- > From: Clinton Gormley <cl...@traveljury.com> > To: Joe Schaefer <joe_schae...@yahoo.com> > Cc: Clinton Gormley <cl...@traveljury.com>; apreq-dev@httpd.apache.org > Sent: Monday, February 16, 2009 4:34:35 AM > Subject: Re: Cookie parsing errors: conflicting information, expected token > not present > > 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 written to be standards compliant, and although more DWIM might be > > nice, it shouldn't come at a cost of violating the specifications (IMO). > > Well, this same argument has been put forward about whether browsers > should just refuse to display invalid HTML, thus breaking most of the > web, or continue trying to do the best with the information available to > them. > > I'm fully in favour of being standards compliant, and I try to ensure > that everything that I create IS standards compliant, but we also have > to deal with browsers with myriad bugs, and it feels a bit lame to just > refuse to communicate with their users, no?
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 the data in the header is malformed and may not be parsed faithfully. If you still want to work with the data, you can always do that by using the error object as if it were an ordinary APR::Request object.
