schneimeister Posted November 11, 2014 Report Posted November 11, 2014 Hello Revive community, I have found a very weird behavior of Revive adserver 3.0.5. The Adserver works like a charme 99% of the time. But sometimes it happens that no ads are displayed anymore. I could track the issue down to a certain cookie OACBLOCK which is normally only set in combination with a certain campaign ID. But in this rare case the cookie is set without any ID. See the following screenshot of the current cookies in Firefox: If this cookie isset, not a single resource can be loaded from the Adserver. See the following screenshot taken from Firebug. It seems the appearance of this cookie triggers a server error. The error only disappears if the cookie is deleted or the browser is restarted (seems to be a cookie only valid for the current session). Should a file a bug report or does anybody have an explanation for this. The error is relatively rare. I would say once per 1000 page loads but all adds are blocked afterwards which makes the bug a pretty serious one. Thanks for your help Martin Quote
9500 Posted May 11, 2015 Report Posted May 11, 2015 We've had a similar problem with Revive 3.1.0. The problem was between nginx and php-fpm. Size of all combined cookies (and thus the whole request) was too large for the buffer between nginx and php-fpm. nginx logged this error: [error] 2264#0: *67969910 upstream sent too big header while reading response header from upstream, client: [redacted], server: [redacted], request: "GET /www/delivery/spcjs.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "[redacted]", referrer: "[redacted]" This stack overflow question was of help:http://stackoverflow.com/questions/23844761/upstream-sent-too-big-header-while-reading-response-header-from-upstream And this guide too: https://gist.github.com/magnetikonline/11312172#determine-fastcgi-response-sizes Quote
Matteo Beccati Posted May 11, 2015 Report Posted May 11, 2015 Yes. The error is caused by the fact that the Cookie header is too long. In this case, OXLIA is getting too big: it is a cookie used for conversion tracking. Add that to the other cookies for frequency capping/blocking and you can easily get this overflow situation. Please try to reduce the number of campaigns with capping and/or conversion tracking. andrewatfornax 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.