Cookie parsing errors: conflicting information, expected token not present
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@@GcCoAzMAAF7rnv8C|d2cb80bdcfcb60a436f99d643349f3fe14e144ec; path=/;
domain=www..com
Set-Cookie:
UID=n4@@GcCoAzMAAF7rnv8C|d2cb80bdcfcb60a436f99d643349f3fe14e144ec; path=/;
domain=www..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=MTj9S8CoAzMAAFEq21YG|c85a9e59db92b261408eb7539ff7f949b92c7d58;
$Version=0;SID=MTj9S8CoAzMAAFEq21YG|c85a9e59db92b261408eb7539ff7f949b92c7d58;$Domain=www..com;$Path=/'
'UID=Gh9VxX8AAAIAAHP7h6AC|2e809a9cc99c2dca778c385ebdefc5cb86c95dc3;
SID=Gh9VxX8AAAIAAHP7h6AC|2e809a9cc99c2dca778c385ebdefc5cb86c95dc3;
$Version=1'
'UID=hCijN8CoAzMAAGVDO2QF|50299f079343fd6146257c105b1370f2da78246a;
SID=hCijN8CoAzMAAGVDO2QF|50299f079343fd6146257c105b1370f2da78246a;
$Path=/; $Domain=www..com'
Expected token not present:
---
'SID=66XUEH8AAAIAAFmLLRkV|2a48c4ae2e9fb8355e75192db211f0779bdce244;
UID=66XUEH8AAAIAAFmLLRkV|2a48c4ae2e9fb8355e75192db211f0779bdce244;
__utma=144149162.4479471199095321000.1234471650.1234471650.1234471650.1;
__utmb=144149162.24.10.1234471650; __utmc=144149162;
__utmz=144149162.1234471650.1.1.utmcsr=szukaj..pl|utmccn=(referral)|utmcmd=referral|utmcct=/internet/0,0.html'
'WT_FPC=id=78.148.13.97-14384.29979421:lv=1234389239171:ss=1234389209078;
UID=ndQ7wcCoAzMAADBMGcwD|b5258531df5af353b4a83d04ddad6b052a8866ec;
__utma=236807049.987764738711978600.1231894870.1234108075.1234389209.15;
__utmz=236807049.1232715122.8.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=www,.com'
'sid=...@x38aaaiaafmfgtqj|c1cabdde0a4f88c471ee7f1b1c3542138f4c61f2;
uid=...@x38aaaiaafmfgtqj|c1cabdde0a4f88c471ee7f1b1c3542138f4c61f2;
__utma=144149162.4479471199095321000.1234471650.1234471650.1234471650.1;
__utmb=144149162.24.10.1234471650; __utmc=144149162;
__utmz=144149162.1234471650.1.1.utmcsr=szukaj..pl|utmccn=(referral)|utmcmd=referral|utmcct=/internet/0,0.html'
'SID=QSRiVn8AAAIAAA3qaCoJ|ff123ba06ae6de89a6453201465331d05276d153;
UID=QSRiVn8AAAIAAA3qaCoJ|ff123ba06ae6de89a6453201465331d05276d153;
__utma=144149162.2660401822504105500.1234181059.1234181059.1234181059.1;
__utmb=144149162.5.10.1234181059; __utmc=144149162;
__utmz=144149162.1234181059.1.1.utmcsr=szukaj..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
mod_vhost_dbd
Hi people, I just signed up, to report a typo. http://modules.apache.org/search.php?id=1753 the link is broken. I'd love to test this, I'm looking for it for some time. Is the maintainer out there? J Jorge
Re: Problems with EOS optimisation in ap_core_output_filter() and file buckets.
On 02/14/2009 12:25 AM, Graham Dumpleton wrote: I know that I can circumvent the EOS optimisation by inserting a flush bucket, but based on documentation it isn't gauranteed that a flush bucket will always propagate down the filter chain and actually push out data. IMHO using a flush bucket would be the way to go here. This should work fine. Regards Rüdiger
Optimize behaviour of reverse and forward worker
Current we set is_address_reusable to 0 for the reverse and forward worker. Is this really needed? IMHO we could reuse the connection if it goes to the same target (we already check this). Regards Rüdiger
Re: Transparent proxy setup works fine, but want to confirm the settings
On 14.02.2009 01:46, Pranav Desai wrote:
On Fri, Feb 13, 2009 at 1:26 AM, Graham Leggettminf...@sharp.fm wrote:
Pranav Desai wrote:
I am trying to setup Apache 2.2.9 as a transparent proxy. So that the
users don't have to configure their browsers. Now the URLs coming in
are relative for transparent proxy, so normally apache tries to look
it up on the filesystem and it obviously fails. So I added a
RewriteRule to convert the relative to absolute URLs.
RewriteEngine On
RewriteRule ^/(.*) http://%{HTTP_HOST}/$1 [P]
RewriteLog logs/rewrite_log
RewriteLogLevel 5
Now, it works perfectly for all traffic expect the one that is
destined for the server itself. E.g.
http://apache_proxy_ip:port/
Whenever I access the above link, the rewrite engine loops and the
server reaches the MaxClient. I have included the log below.
That would make perfect sense though, you are asking the server to send you
to the server prefixed with the host header, and when you use the hostname
of the proxy server itself, you create a loop by definition, which means...
So, I added some conditions to not apply the RewriteRule for HOST
destined to the server.
RewriteCond %{HTTP_HOST} !10.1.0.206.*
RewriteRule ^/(.*) http://%{HTTP_HOST}/$1 [P]
...this is a sensible workaround.
I wanted to confirm if this is the right way to do transparent proxy
or is there a better way to make it more solid ?
In theory this will work as is, I am not sure whether there is an option in
the proxy to do this natively without the need for rewrite.
I checked the proxy, and there isn't anything to specifically do this,
but maybe I could have used some ReverseProxy config to get the same
behavior, but I thought RewriteRule was a bit cleaner.
If you do reverse proxy only via RewriteRule, then you end up using no
connection pool (i.e. no persistent connections) to the HTTP_HOSTs. In
case there are only few of those (or few that carry the most load), you
would better define a connection pool to them with ProxyPass. If you
want to keep your rewrite construction, you can use a URL in ProxyPass,
which you know won't really occur:
ProxyPass /does/not/exist http://most.important.host/ smax=... ...
Regards,
Rainer
Re: Transparent proxy setup works fine, but want to confirm the settings
On 02/14/2009 08:59 PM, Rainer Jung wrote: If you do reverse proxy only via RewriteRule, then you end up using no connection pool (i.e. no persistent connections) to the HTTP_HOSTs. In case there are only few of those (or few that carry the most load), you would better define a connection pool to them with ProxyPass. If you want to keep your rewrite construction, you can use a URL in ProxyPass, which you know won't really occur: ProxyPass /does/not/exist http://most.important.host/ smax=... ... He is doing forward proxying here and not reverse proxying. In order to create a pool IMHO the better approach is Proxy http://most.important.host/ ProxySet smax=... /Proxy Regards Rüdiger
Re: Optimize behaviour of reverse and forward worker
On 14.02.2009 15:09, Ruediger Pluem wrote: Current we set is_address_reusable to 0 for the reverse and forward worker. Is this really needed? IMHO we could reuse the connection if it goes to the same target (we already check this). By check you mean the code in ap_proxy_determine_connection()? The check there seems only to happen in the case were the client reuses a keepalive connection. I have the feeling, that disablereuse and is_address_reusable are used almost in the same way at the moment, except for mod_proxy_ftp. Both attributes are always checked together, so both imply the same behaviour. What's the expected case were you can actually reuse the backend connection? A client using HTTP Keep-Alive and a backend connection that's not too busy, so that consecutive client requests to the same backend can be send via the same backend connection? Could that be generalized to concurrent client connections C1, C2, ... mapping to different backend connections B1, B2, ..., each of them reused for the same client connection as long as it lasts (C1 - B1, C2- B2, ...)? If so, we would also need to find good default pool configuration for the reverse and forward worker. There's also a use case, were proxy requests are defined via RewriteRule. In case the host in the rewrite rule is a constant string, we would benefit from initializing a real worker, not using the default workers. Regards, Rainer
Re: Transparent proxy setup works fine, but want to confirm the settings
On Sat, Feb 14, 2009 at 1:03 PM, Ruediger Pluem rpl...@apache.org wrote: On 02/14/2009 08:59 PM, Rainer Jung wrote: If you do reverse proxy only via RewriteRule, then you end up using no connection pool (i.e. no persistent connections) to the HTTP_HOSTs. In case there are only few of those (or few that carry the most load), you would better define a connection pool to them with ProxyPass. If you want to keep your rewrite construction, you can use a URL in ProxyPass, which you know won't really occur: ProxyPass /does/not/exist http://most.important.host/ smax=... ... He is doing forward proxying here and not reverse proxying. In order to create a pool IMHO the better approach is Proxy http://most.important.host/ ProxySet smax=... /Proxy I am confused a bit here. With the RewriteRule I mentioned earlier will I lose persistent connections for transparent proxy connections ? And the above settings in addition to the RewriteRules will help in getting persistent connections ... ? -- Pranav Regards Rüdiger
