Return-Path: Delivered-To: apmail-httpd-apreq-dev-archive@www.apache.org Received: (qmail 27762 invoked from network); 14 Feb 2009 13:21:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Feb 2009 13:21:45 -0000 Received: (qmail 76063 invoked by uid 500); 14 Feb 2009 13:21:45 -0000 Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org Received: (qmail 76034 invoked by uid 500); 14 Feb 2009 13:21:44 -0000 Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list apreq-dev@httpd.apache.org Received: (qmail 76025 invoked by uid 99); 14 Feb 2009 13:21:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Feb 2009 05:21:44 -0800 X-ASF-Spam-Status: No, hits=2.8 required=10.0 tests=SPF_PASS,WHOIS_PRIVPROT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of clint@traveljury.com designates 84.45.94.189 as permitted sender) Received: from [84.45.94.189] (HELO mail.traveljury.com) (84.45.94.189) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Feb 2009 13:21:33 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.traveljury.com (Postfix) with ESMTP id E194BE09B0 for ; Sat, 14 Feb 2009 13:21:11 +0000 (GMT) X-Virus-Scanned: amavisd-new at traveljury.com Received: from mail.traveljury.com ([127.0.0.1]) by localhost (hansolo.iannounce.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE+RAcVM6xoS for ; Sat, 14 Feb 2009 13:21:04 +0000 (GMT) Received: from [192.168.5.100] (unknown [89.131.29.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mail.traveljury.com (Postfix) with ESMTP id E1900E0989 for ; Sat, 14 Feb 2009 13:21:03 +0000 (GMT) Subject: Cookie parsing errors: conflicting information, expected token not present From: Clinton Gormley To: apreq-dev@httpd.apache.org Content-Type: text/plain; charset=UTF-8 Date: Sat, 14 Feb 2009 14:21:51 +0100 Message-Id: <1234617711.4089.19.camel@getafix.traveljury.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Hiya There has been some discussion about cookie parsing errors with libapreq2 on the modperl list, and Joe Schafer said: What version of apreq was this? And did you report it to the apreq-dev@ mailing list? While I have previously reported the errors I see to the modperl list, I thought I'd send them here as well. This is in apache 2.2.4 with libapreq2-2.08, on linux x86_64. The code I use to parse the cookies is as follows: ------------------------------------------------------------------------ my $req = APR::Request::Apache2->handle( $self->r ); my %cookies; if ( $req->jar_status =~ /^(?:Missing input data|Success)$/ ) { my $jar = $req->jar; foreach my $key ( keys %$jar ) { $cookies{$key} = $jar->get($key); } } ## Send warning with headers to explain bad cookie else { warn( "COOKIE ERROR: " . $req->jar_status . "\n" . Data::Dumper::Dumper( $self->r->headers_in() ) ); } ------------------------------------------------------------------------ The headers which get passed back to my users look like this: Set-Cookie: SID=n4@@GcCoAzMAAF7rnv8AAAAC|d2cb80bdcfcb60a436f99d643349f3fe14e144ec; path=/; domain=www.xxxx.com Set-Cookie: UID=n4@@GcCoAzMAAF7rnv8AAAAC|d2cb80bdcfcb60a436f99d643349f3fe14e144ec; path=/; domain=www.xxxx.com; expires=Sun, 14-Feb-2010 13:06:36 GMT We run various sites, all of which have Google Analytics plus usually some other form of click tracking and advertising, which set their own cookies. Below are examples of Cookie headers that caused libapreq to throw one of two errors: Conflicting information: ------------------------ 'UID=MTj9S8CoAzMAAFEq21YAAAAG|c85a9e59db92b261408eb7539ff7f949b92c7d58; $Version=0;SID=MTj9S8CoAzMAAFEq21YAAAAG|c85a9e59db92b261408eb7539ff7f949b92c7d58;$Domain=www.xxxx.com;$Path=/' 'UID=Gh9VxX8AAAIAAHP7h6AAAAAC|2e809a9cc99c2dca778c385ebdefc5cb86c95dc3; SID=Gh9VxX8AAAIAAHP7h6AAAAAC|2e809a9cc99c2dca778c385ebdefc5cb86c95dc3; $Version=1' 'UID=hCijN8CoAzMAAGVDO2QAAAAF|50299f079343fd6146257c105b1370f2da78246a; SID=hCijN8CoAzMAAGVDO2QAAAAF|50299f079343fd6146257c105b1370f2da78246a; $Path="/"; $Domain="www.xxxx.com"' Expected token not present: --------------------------- 'SID=66XUEH8AAAIAAFmLLRkAAAAV|2a48c4ae2e9fb8355e75192db211f0779bdce244; UID=66XUEH8AAAIAAFmLLRkAAAAV|2a48c4ae2e9fb8355e75192db211f0779bdce244; __utma=144149162.4479471199095321000.1234471650.1234471650.1234471650.1; __utmb=144149162.24.10.1234471650; __utmc=144149162; __utmz=144149162.1234471650.1.1.utmcsr=szukaj.xxxx.pl|utmccn=(referral)|utmcmd=referral|utmcct=/internet/0,0.html' 'WT_FPC=id=78.148.13.97-777714384.29979421:lv=1234389239171:ss=1234389209078; UID=ndQ7wcCoAzMAADBMGcwAAAAD|b5258531df5af353b4a83d04ddad6b052a8866ec; __utma=236807049.987764738711978600.1231894870.1234108075.1234389209.15; __utmz=236807049.1232715122.8.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=www,xxxx.com' 'SID=6mF@x38AAAIAAFmFGtQAAAAJ|c1cabdde0a4f88c471ee7f1b1c3542138f4c61f2; UID=6mF@x38AAAIAAFmFGtQAAAAJ|c1cabdde0a4f88c471ee7f1b1c3542138f4c61f2; __utma=144149162.4479471199095321000.1234471650.1234471650.1234471650.1; __utmb=144149162.24.10.1234471650; __utmc=144149162; __utmz=144149162.1234471650.1.1.utmcsr=szukaj.xxxx.pl|utmccn=(referral)|utmcmd=referral|utmcct=/internet/0,0.html' 'SID=QSRiVn8AAAIAAA3qaCoAAAAJ|ff123ba06ae6de89a6453201465331d05276d153; UID=QSRiVn8AAAIAAA3qaCoAAAAJ|ff123ba06ae6de89a6453201465331d05276d153; __utma=144149162.2660401822504105500.1234181059.1234181059.1234181059.1; __utmb=144149162.5.10.1234181059; __utmc=144149162; __utmz=144149162.1234181059.1.1.utmcsr=szukaj.xxxx.pl|utmccn=(referral)|utmcmd=referral|utmcct=/internet/0,0.html' 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. hope this info helps thanks Clint