Re: Cookie parsing errors: conflicting information, expected token not present

[Clinton Gormley <cl...@traveljury.com>]

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?

clint
     

Re: Cookie parsing errors: conflicting information, expected token not present

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message ----

> From: Clinton Gormley <cl...@traveljury.com>
> To: Joe Schaefer <jo...@yahoo.com>
> Cc: Clinton Gormley <cl...@traveljury.com>; apreq-dev@httpd.apache.org
> Sent: Monday, February 16, 2009 5:09:46 AM
> Subject: Re: Cookie parsing errors: conflicting information, expected token not present
> 
> 
> > 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.
> 
> That's interesting - I didn't know you could do that.

APR::Request::Error is a subclass of APR::Request.  What it does differently from
APR::Request is that it runs all the commands with errors disabled.  Most of the
stuff you are worried about would be adequately handled by just doing something
silly like

   my $req = APR::Request::Apache2->handle($r);
   my $jar = eval {$req->jar} || $@->jar; # best effort


      

Re: Cookie parsing errors: conflicting information, expected token not present

[Clinton Gormley <cl...@traveljury.com>]

> 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.

That's interesting - I didn't know you could do that.

thanks - will await your results with interest :)

clint
> 
> 
>       

Re: Cookie parsing errors: conflicting information, expected token not present

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message ----

> From: Clinton Gormley <cl...@traveljury.com>
> To: Joe Schaefer <jo...@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.