Hello. We place ads on the forums. Links pass through our tracker. So it turns out that I see the cookies of this forum. Session minimum. From their banner there is a redirect to them (apparently also track), and then to us. It is worth noting that this happens when for some reason we have HTTP 1.0 set to $ _SERVER [SERVER_PROTOCOL]. The forum works for them on https. How is this possible? Maybe in http 1.0 cookies are not bound to domains. Does not depend on the browser (user agents are different) I tried to reproduce the bug, but it did not work out. At least push where to dig.

UPDATE. An example of such a user.
Always have such a bug [SERVER_PROTOCOL] => HTTP / 1.0.
Another strange thing is that Referer is equal to the link to which it came.
Maybe some proxy curves yuzayut.

Datetime: 2015-04-04 08:36:36 IP: 142.54.161.130 Request: /GDW Referer: http://our-shot-link.com/GDW Country: US City: Kansas City Unique: No SERVER: ( [REDIRECT_STATUS] => 200 [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.65 Safari/537.36 OPR/26.0.1656.24 [HTTP_REFERER] => http://our-shot-link.com/GDW [HTTP_HOST] => our-shot-link.com [HTTP_COOKIE] => ALIENSID=a64bf2914d1e32cfe2c0dca7dc5f23a2 [PATH] => /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/renmaster/bin [SERVER_SIGNATURE] => [SERVER_SOFTWARE] => Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips [SERVER_NAME] => our-shot-link.com [REMOTE_ADDR] => 142.54.161.130 [DOCUMENT_ROOT] => /home/dev/our-shot-link.com/current/www [SCRIPT_FILENAME] => /home/dev/our-shot-link.com/current/www/index.php [REMOTE_PORT] => 59079 [REDIRECT_URL] => /GDW [GATEWAY_INTERFACE] => CGI/1.1 [SERVER_PROTOCOL] => HTTP/1.0 [REQUEST_METHOD] => GET [QUERY_STRING] => [REQUEST_URI] => /GDW [SCRIPT_NAME] => /index.php [PHP_SELF] => /index.php [REQUEST_TIME_FLOAT] => 1428125796.03 [REQUEST_TIME] => 1428125796 ) COOKIE: ( [ALIENSID] => a64bf2914d1e32cfe2c0dca7dc5f23a2 ) REQUEST HEADERS: ( [Accept] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 [User-Agent] => Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.65 Safari/537.36 OPR/26.0.1656.24 [Referer] => http://our-shot-link.com/GDW [Host] => our-shot-link.com [Cookie] => ALIENSID=a64bf2914d1e32cfe2c0dca7dc5f23a2 ) RESPONSE HEADERS: ( [Location] => http://destination-url.com/top )

  • @aixx, I see them in the $ _COOKIE variable. There at least their session, because the name of the cookies they have is not a standard PHPSESSID. Sometimes Google still skips __utm ... We don’t have Google analytics. Even the session is not set. We just write a click and send the user further. We sent it via a redirect with code 307, but HTTP 1.0 does not support it, so we had errors. So we noticed it. I could not reproduce the error. The request was made with HTTP 1.0, Apache made HTTP 1.0 also respond, but $ _SERVER [SERVER_PROTOCOL] is still equal to 1.1. I suspect a bug in the protocol 1.0, or what proxy users may have. - Ray

1 answer 1

You misunderstood something.

Cookies are sent by the browser, it is the browser that does not send cookies to where it should be, so there’s no point in looking for a “bug” in your Apache. The problem simply does not exist.

Maybe some crooked bots unsuccessfully imitate cookies, which you should not have?

  • I know that the browser responds to cookies. Kopal old specifications - before cookies really were not tied to domains, but it was in the 90s. The option of bots is very unlikely: user agents are different (from IE 6, to different versions of chrome), ip are completely different (US, RF, UK, etc.). And there is nothing to catch these bots. We simply record the information about the transition to assess the effectiveness of advertising. - Ray
  • Updated question by example of user - Ray