I am experiencing intermittent issues when using the Pingdom monitoring tool to check the status of my website.
Every 10-15 minutes I get an alert to say that a 302 has been found. What I can't understand is - i'm not doing any 302 temporary redirects. I am, however, doing 301 redirects (in certain circumstances).
Could this be a false positive from Pingdom?
Also, I have a redirect in code that does this. Would not specifying the HTTP response code
cause an issue here?
header('Location: http://www.ayrshireminis.com');
exit();
The Pingdom data:
Request 1
GET / HTTP/1.0
User-Agent: Pingdom.com_bot_version_1.4_(http://www.pingdom.com/)
Host: www.ayrshireminis.com
Received header
302 Found
Date: Tue, 24 Jul 2012 13:13:25 GMT
Server: Apache
Set-Cookie: prev_session_id=2a7001f5caa79bd36995953bf4853675; expires=Thu, 23-Aug-2012 13:13:25 GMT; path=/; domain=ayrshireminis.com
Location: http://www.ayrshireminis.com/
Vary: Accept-Encoding
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Looks to me like a cookie is being set on the response, then redirecting you to the same page. Because Pingdom uses a number of different monitoring sources, that cookie redirect behavior will cause a lot of problems. Then again, you may need it for actual website visitors.
Rather than monitor the root of the webpage, I would recommend creating a separate /status page just for Pingdom that:
Doesn't set or use cookies
Performs a cheap end-to-end health check of the application and backing services
Returns a 200 response code only if everything checks out OK
Related
I'm experiencing a strange issue on a WooCommerce installation my company has taken over. It's not us who built it and unfortunately it's pretty crappy built so I'm not so sure what's actually going on in there.
It suddenly started to "force" https connections, but as far as I know nothing has changed in nether the code nor from the admin. We are running Git on the server and nothing has changed in the working tree, and I searched the uploads folder for suspicious files with no results. It's very unlikely some kind of malware. The site is not set up with https/ssl so this does of course trigger a timeout.
I checked the database and both home_url and site_url are set to "http://...". The WooCommerce option "force ssl" is set to false. Also we are running the plugin "Better WP Security/iThemes Security" which also offers a "force ssl"-option but that one is set to false too.
I tried setting both the constants FORCE_SSL_ADMIN and FORCE_SSL_LOGIN to false in wp-config.php - still no luck. Also I tried using .htaccess rewrite rules but that didn't help either.
It seems to be connected with a request header; HTTPS: 1 (tested with $ curl -I -H"HTTPS: 1" http://...). When that one is set to 0 this does not happen. However Chrome seems to send it by default, which is not the case for other browsers. I tried clearing cookies/data etc. Problem appears in my colleague's browser as well (and she has never visited the site before). Hosting company says this is not related to server configuration.
Has anyone experienced this before, or know to what it could be related to?
Update:
Running curl -I -H"HTTPS: 1" http://www.example.com/wp-admin/ pretty much confirms this has something to do with Wordpress. The cookies are set by WPML which indicates Wordpress is initialized. Check the Location: header:
HTTP/1.1 302 Moved Temporarily
Server: Apache
X-Powered-By: PHP/5.6.11
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Set-Cookie: _icl_current_admin_language=sv; expires=Wed, 22-Jul-2015 16:06:25 GMT; Max-Age=7200; path=/wp-admin/
Set-Cookie: _icl_current_language=sv; expires=Thu, 23-Jul-2015 14:06:25 GMT; Max-Age=86400; path=/
Set-Cookie: PHPSESSID=xxx; path=/
Location: https://www.example.com/wp-login.php?redirect_to=https%3A%2F%2Fwww.example.com%2Fwp-admin%2F&reauth=1
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8
Date: Wed, 22 Jul 2015 14:06:26 GMT
X-Varnish: nnn
Age: 0
Via: 1.1 varnish
Connection: keep-alive
http://develop.woothemes.com/woocommerce/2015/07/woocommerce-2-3-13-security-and-maintenance-release/
Updating Woocommerce to 2.3.13 fixed it for me
#Zertuk's solution is correct: upgrading to the latest WooCommerce should fix the issue because of the change that #Zertuk has linked.
To give more detail: Chrome has implemented the Upgrade Insecure Requests specification from the World Wide Web Consortium (W3C). Section 3.2.1 of that specification is The HTTPS HTTP Request Header Field which states
3.2.1. The HTTPS HTTP Request Header Field
The HTTPS HTTP request header field sends a signal to the server
expressing the client’s preference for an encrypted and authenticated
response, and that it can successfully handle the
upgrade-insecure-requests directive in order to make that preference
as seamless as possible to provide.
This preference is represented by the following ANBF:
"HTTPS:" *WSP "1" *WSP
WooCommerce's is_ssl() function before version 2.3.13 was incorrectly rewriting all the URLs in the response if the HTTPS: 1 header was set.
Upgrading to the latest version of WooCommerce (currently 2.3.13) fixes the bug.
I fixed this issue by turning off the Force SSL setting within WooCommerce Settings, and then explicitly setting these 3 WooCommerce pages to use SSL via the checkbox provided as part of this plugin (on the Edit Page screen).
The pages that needing SSL according to WooCommerce are:
1. Checkout
2. Checkout -> Pay
3. My Account
and also try,
<?php
if (is_ssl()) {
//action to take for page using SSL
}
?>
Returns true if the page is using SSL (checks if HTTPS or on Port 443).
Kirby is right.
I did a quick fix modifying the Wordpress core function is_ssl().
I return false at the beginning of the function because some of my websites do not have SSL.
It's not recommended modify the core of Wordpress because of the updates, but I can control that.
I have following problem that's bugging my mind completely. I have to take over this cms from someone who doesn't want to care for it anymore and is giving no support whatsoever.
Situation is as follows: on the site there are several photo albums which are populated by reading a directory in php. All is good there, pictures are shown in the order they are read. In the management system, these pictures can be changed in order by an up or down-button. The way this is done is by swapping the image's filenames. This works, when I change the order for an image i can see server-side the filenames have actually been swapped.
This is however not the case on the site, at least not immediately: it takes an average of 10 minutes to see the images swapped there. Ofcourse, my client can't work like this, and he claims it has always worked before. I have tried to turn off caching browser-side, this hasn't helped. I can also note the changes take effect on the same time in IE and FF. I tried several ways of turning off cache server-side in php too, also to no avail.
Is there any other place where I should be looking or could there be another reason why these changes don't take effect immediately?
In addition, changes i make to javascript don't get picked up immediately too. I installed fiddler and this is the request header for that js file:
GET http://www.nobel-country-gite.be/admin/modules/Photoalbum/js/album.js HTTP/1.1
Accept: application/javascript, /;q=0.8
Referer: http://www.nobel-country-gite.be/admin/index.php?page=pic&album=24
Accept-Language: nl-BE
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
If-Modified-Since: Wed, 27 May 2015 15:55:12 GMT
If-None-Match: "ba1248f5-138b-5171244a92f66"
DNT: 1
Host: www.nobel-country-gite.be
Pragma: no-cache
Cookie: __utmc=39679548; __utma=39679548.1608184058.1429963360.1432662247.1432664636.7; __utmz=39679548.1429963360.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmc=1; PHPSESSID=7uge1ltg2rc11q63untthrc5s1; __utma=1.459796341.1429963360.1432662247.1432664636.7; __utmz=1.1429963360.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Response header is as follows:
HTTP/1.1 304 Not Modified
Server: Apache
Last-Modified: Wed, 27 May 2015 15:55:12 GMT
ETag: "ba1248f5-138b-5171244a92f66"
Vary: Accept-Encoding
Content-Type: application/javascript
Date: Wed, 27 May 2015 16:57:55 GMT
X-Varnish: 1826689067 1825041752
Age: 556
Via: 1.1 varnish
Connection: keep-alive
I would expect the answer to be different instead of 'not modified'?
Edit - upon waiting a few minutes and refreshing the page again, the response for this file is what is expected:
HTTP/1.1 200 OK
Server: Apache
Last-Modified: Wed, 27 May 2015 16:57:30 GMT
ETag: "ba1248f5-1387-51713237ac28e"
Vary: Accept-Encoding
Content-Type: application/javascript
Transfer-Encoding: chunked
Date: Wed, 27 May 2015 17:03:43 GMT
X-Varnish: 1827728442
Age: 0
Via: 1.1 varnish
Connection: keep-alive
I couldn't help but notice you are using Varnish (indicated by the X-Varnish response header). Varnish is a caching reverse proxy, which means your pages are not just being cached by the browser, but also on the server (by Varnish). Your browser connects to Varnish, and Varnish connects to your Apache backend.
The first response header includes "Age: 556" - that's the cached version's age in seconds (almost 10 minutes). Then the age comes across as "0" when the page refreshes - that's because Varnish has updated its cache. Probably you can access the page over HTTPS to see your changes immediately reflected (Varnish doesn't work for HTTPS and most people don't bother setting up an HTTPS cache), or you can generally add garbage GET parameters to your URL (e.g. "?bogus=123") to force Varnish to re-fetch the page (this won't make other users see the new version, since they'll be accessing via the normal URLs).
Fixes: You can use varnishadm to ban (expire) certain URLs in Varnish when you've made a change; you can modify the "Cache-Control" or "Expires" headers your CMS/Apache (via PHP, .htaccess, etc.) produces to reduce cache time (Varnish completely respects cache control headers in its caching strategy); you can change Varnish's behavior by editing the relevant VCL (usually "default.vcl"); or you can accept that caches are generally good (they save a lot of time and resources in generating the response), and maybe a 10 minute delay is an acceptable trade-off.
When I did a networks course I learned about HTTP Request and Response messages and I know how to code in php reasonably enough to get around. Now my question is, the PHP has to have some link to HTTP request and response message but how. I can't seem to see the link between the two. My reasoning for asking this is that I am using the Twitter API console tool to query their api. The tool sends the following HTTP request:
GET /1.1/search/tweets.json?q=%40twitterapi HTTP/1.1
Authorization:
OAuth oauth_consumer_key="DC0se*******YdC8r4Smg",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1410970037",oauth_nonce="2453***055",oauth_version="1.0",oauth_token="796782156-ZhpFtSyPN5K3G**********088Z50Bo7aMWxkvgW",oauth_signature="Jes9MMAk**********CxsKm%2BCJs%3D"
Host:
api.twitter.com
X-Target-URI:
https://api.twitter.com
Connection:
Keep-Alive
and then I get a HTTP response:
HTTP/1.1 200 OK
x-frame-options:
SAMEORIGIN
content-type:
application/json;charset=utf-8
x-rate-limit-remaining:
177
last-modified:
Wed, 17 Sep 2014 16:07:17 GMT
status:
200 OK
date:
Wed, 17 Sep 2014 16:07:17 GMT
x-transaction:
491****a8cb3f7bd
pragma:
no-cache
cache-control:
no-cache, no-store, must-revalidate, pre-check=0, post-check=0
x-xss-protection:
1; mode=block
x-content-type-options:
nosniff
x-rate-limit-limit:
180
expires:
Tue, 31 Mar 1981 05:00:00 GMT
set-cookie:
lang=en
set-cookie:
guest_id=v1%3A14109******2451388; Domain=.twitter.com; Path=/; Expires=Fri, 16-Sep-2016 16:07:17 UTC
content-length:
59281
x-rate-limit-reset:
1410970526
server:
tfe_b
strict-transport-security:
max-age=631138519
x-access-level:
read-write-directmessages
So how do these HTTP request and response messages fit into PHP? Does PHP auto generate this? How do I add authorization to PHP requests etc? I'm confused about the deeper workings of PHP
When the client sends the HTTP request to the server, there has to be something to receive the HTTP request, which is called a web server. Examples of web servers are Apache, IIS, Nginx, etc. You can also write your own server, which can handle input however it wants. In this case, I'll assume that you are requesting a PHP file.
When the web server captures the HTTP request, it determines how it should be handled. If the file requested is tweets.json, it will go make sure that file exists, and then pass control over to PHP.
PHP then begins its execution, and performs any logic that the script needs to do, meaning it could go to the database, it reads, writes and makes decisions based cookies, it does math, etc.
When the PHP script is done, it will return a HTML page as well as a bunch of headers back to the web server that called it. From there, the web server turns the HTML page and headers back into a HTTP request to respond.
That is a pretty simple overview, and web servers can work in many different ways, but this is a simple example of how it could work in a introductory use-case. In more complex scenarios, people can write their own web servers, which perform more complex logic inside of the web server software, rather than passing it off to PHP.
When it comes down to it, PHP files are just scripts that the web server executes when they are called, they provide the HTTP request as input, and get a web page and headers as output.
Why do some web applications/servers/etc issue a non-standard, second, Status header. For example, I'm working with an existing application where, in addition to that HTTP protocal line, there's a second header named status
$ curl -I 'http://example.com/404'
HTTP/1.1 404 Not Found
//...
Status: 404 Not Found
//...
and a stock apache 404 doesn't include it
HTTP/1.1 404 Not Found
Date: Thu, 24 Jul 2014 13:16:28 GMT
Server: Apache/2.2.3 (CentOS)
Connection: close
Content-Type: text/html; charset=iso-8859-1
I'd write this off as one quirky application developer, but I've seen this behavior is other applications over the years, and the Wikipedia article on HTTP headers mentions this header, although it points out the header isn't included in RFC7230.
? "Status" is not listed as a registered header. The "Status-Line" of a "Response" is defined by RFC7230[23] without any explicit "Status:" header name.
Does anyone know the deal here? Is there some browser that needed this at some point? Still needs it? Is this some weird bit of SEO voodoo?
Is there any practical effect to including/not-including this field? Has there ever been?
(I'm specifically working with PHP, if that matters)
I'm using PHP to redirect a page back to the previous page with the following:
header("Location: {$_SERVER['HTTP_REFERER']}");
This set of pages will only be used by internal users, so I'm not terribly concerned about the fact that the referer will not always be available.
The problem I'm running in to is that if the referer looks like http://subdomain.domain.com/test.php?id=13, the redirect ends up going to http://subdomain.domain.com/.domain.com/test.php?id=13. Notice the additional .domain.com/ in the url.
I've tested by hardcoding the value, and it causes the problem as well. phpMyAdmin seems to suffer the same issue, but only on this particular server.
If this is not an SO question, please move accordingly.
EDIT: per #yaggo
test.php contains only header("Location: http://subdomain.domain.com/test2.php");
curl --head --referer 'http://subdomain.domain.com/' 'http://subdomain.domain.com/test.php'
HTTP/1.1 302 Found
Server: nginx/0.7.64
Date: Fri, 02 Apr 2010 17:21:45 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.2.12-pl0-gentoo
Location: .domain.com/test2.php
I've recreated both your programs on my server
once with
header("Location: http://subdomain.domain.com/some/place");
and once with
header("Location: {$_SERVER['HTTP_REFERER']}");
and both give the corret result
curl --head --referer 'http://subdomain.domain.com/some/place' 'http://subdomain.domain.com/test.php'
HTTP/1.1 302 Found
Date: Fri, 02 Apr 2010 17:48:54 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: PHP/5.1.2
Location: http://subdomain.domain.com/some/place
Connection: close
Content-Type: text/html
I'm using a different version of PHP and a different webserver, so there's two things to investigate.
It seems that your nginx configuration is causing the problems.
Its totally possible that nginx is modifying the response headers. This is not by default - you could have a configuration that is aimed for it to behave as a reverse proxy etc.
Have you tried testing the redirect on a nginx with its default configuration?
[...] the redirect ends up going to http://subdomain.domain.com/.domain.com/test.php?id=13.
Can you isolate the problem a little bit more? Is that url exactly what is returned by PHP or is it how browser (Chrome?) sees it?
Can you check the actual headers e.g. with curl:
$ curl --head --referer 'http://your-referer' 'http://your-page/'
header("Location: ".$_SERVER['HTTP_REFERER']);
Edited:
Check you .htaccess settings or if no solution found u can use preg_replace to remove that last ".domain.com"
but it looks that is a not a php error.
OR use javascript to get the referer address...
then use window.location.href = url; to redirect ...