So I just got a nasty surprise when I deployed some code I thought I'd tested. It would seem there must be some difference between my test machine and my server. The exact same code, featuring a header redirect, worked perfectly on my test machine and not at all on the server. The redirect on the server simply didn't happen, leaving a blank page as a result.
The header is called somewhere in the middle of the script - but nothing will have been output yet. It doesn't output anything until the very end of the script. Long after everything else is run. It buffers everything.
Both server and test machine are running the same PhP version, the same Apache version. Is there something in the configuration files that would allow the header to happen for one and not in the other? Is there something else going on here that would cause it to fail?
EDIT:
Here's the line that sets the header:
public function setRedirect($url) {
header('Location: '.$url);
}
And here's the code that calls that:
$url = new URL('index');
$this->layout->setRedirect($url->toString());
Where URL::toString() always generates a fully qualified domain name, in this case: http://domain/index.php?action=index
I checked both Php and Apache error logs. Nada.
Probably there was some whitespace or other form of output before the header call.
This is only work if you the ini setting output-buffering is on (or if you explicitly start output buffering, but in that case, the redirect should work in both computers).
You can confirm this by turning on error reporting.
Use Fiddler or some other client-side tool to check your headers. Determine that the Location: header is actually being sent. Also, some browsers are picky in the order that headers need to be sent.
I think the most likely explanation is that an error is causing the script to exit on your server, and you have display errors turned off (hence the blank screen). I would suggest checking the Apache error long on your server to see if PHP is putting something in there.
Otherwise you could use a browser extension like LiveHTTPHeaders (for Firefox) to see if the location header is being sent at all, or try debugging the script to see if it's even getting as far as that header call.
I think your server puts some script in your pages to track visitors and give you traffic stats or for a similar purpose. Ideally, you should get an error for this but may be your server has error reporting disabled which gives you a blank page.
I suggest you to run a script with a syntax error and check weather your server has error reporting disabled.
Related
In the php manual (http://php.net/manual/en/function.header.php) I find the following about http headers:
QUOTE
Remember that header() must be called before any actual output is sent, either by normal HTML tags, blank lines in a file, or from PHP. It is a very common error to read code with include, or require, functions, or another file access function, and have spaces or empty lines that are output before header() is called. The same problem exists when using a single PHP/HTML file.
<html>
<?php
/* This will give an error. Note the output
* above, which is before the header() call */
header('Location: http://www.example.com/');
exit;
?>
ENDQUOTE
I tried this now (making a study of the HTTP protocol) and find that this doesn't seem to be an issue anymore; I wonder what has changed: has the way php deals with parsing webpages changed? I tried several browsers (Chrome, IE10, IE7) and OS (Windows 8.1, XP) and none of them seem to have an issue with this anymore (see informaticaschool.net76.net/httpdemo3.php for a page that includes exactly the above code example, not giving an error.
For the details of the php version running on that server (I also tried a different apache server) see informaticaschool.net76.net/phpinfo.php.
I admit its a bit of a strange thing to ask why an error does NOT occur but as pointed out i'm studying the workings of http. Looking into a Wireshark trace now to find out what happens exactly in this case, that I knew to be an issue before, I am now surprised to find that NO error appears (and not finding an explanation for it in the php manual).
That server has output_buffering turned on, so all output is buffered and held, which allows you to send headers to the web server even after you have already produced output. See the canonical answer about this issue, section "But it worked on the other server!?".
You must send headers before send output buffer.
Or you can use functions ob_start and ob_end_flush to save output buffer.
I have the following tag for when a user is successfully logged in:
header('Location: /members');
It always used to work. Now, however, when I try to load the page, Chrome gives me this error:
HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request.
On Firefox, I just get a blank page. When I comment the header statement out, it works, but without the redirect (obviously).
I have tried it with output buffering on and off, with the same effect. Any ideas?
Edit: I have a PHP header statement at the beginning of the code that redirects users to the member page if they are already logged in. Could this be affecting it? I'm not getting any headers already sent errors...
Just put error_reporting(E_ALL) and ini_set("display_errors", 1) and you'll see what's wrong.
Install the HTTP extension and use this instead:
http_redirect('/members');
This should do the trick. If you don't have it installed. you can mimic what it does. It's explained in detail on the manual page, the steps in short:
Create an absolute URI from the relative URI as redirects by RFC must have one.
Check if headers have already been send, if so don't send header, otherwise do.
Display a HTTP response body with the link of the redirect.
Exit the script.
If you don't follow the specs, you can not expect that things work with a browser. Many examples given in the internet are not giving conform redirects, so don't be misguided by bad examples.
Next to that - as already suggested by others - turn on error reporting on your development box so you are aware of any notices and warnings that your code produces. Deal with those issues as well.
I want to redirect to www.yahoo.com from my codeIgniter application. I write code like this :
redirect("http://www.yahoo.com");
It is working fine in my local computer (Windows vista / WAMP) but when I upload to linux server it just show blank screen and not redirect.
Try using the refresh method:
redirect('http://www.yahoo.com', 'refresh');
Blank screen normally means a fatal error somewhere. Check your logs!
And check your headers too. Curl it or use a HTTP Client to see what is being returned.
Debugging helps with these things. We are just random people on the internet without access to your computer, so without more information (hell you didnt even mention which version of CI you are using) we are all just taking guesses.
you probably want header: header('location: http://www.yahoo.com');
Try enabling error_reporting(E_ALL) to see if there are any errors that indicate output is being sent before those headers (specified by redirect()).
A common issue that I find is that the means of uploading (e.g. deploying over FileZilla) will sometimes insert lines depending on the transfer mode I guess. I've seen those same files I uploaded via FileZilla double spaced entirely. More than likely, you have an empty line at the top of your controller. Best way to find out is to edit that controller on the server (e.g. File Editor or re-download and view it) and see if this is the case.
I'm working on building a PHP based proxy script to access a particular ASP.NET page that uses lots of AJAX. So far most of the website works, but one of the forms produces the following error upon submittal:
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near '
<!DOCTYPE html P'.
I've checked the headers that my proxy script sends/receives, and they're identical to what would actually be sent my a web browser like FF. I've checked the page source to make sure everything that should be in tact is so. I've also verified there aren't any javascript errors on the page.
Can anyone suggest an approach to continue troubleshooting the issue?
Thanks.
If you miss an AJAX call in your proxy, there could be some cross domain errors. Also, make sure you are not accidentally stripping any non-standard headers like X-MicrosoftAjax.
I'm having a problem implementing custom 404 error pages on my Windows/IIS/PHP webhost. Whenever I try to send the 404 status message in the header, no content is sent to the client and a blank page is displayed instead.
Here is a very simple script I'm using:
<?php
header('HTTP/1.1 404 Not Found');
header('Status: 404 Not Found');
var_dump(headers_list());
?>
On my dev machine the output (displayed in a browser) is
array(2) { [0]=> string(23) "X-Powered-By: PHP/5.2.6" [1]=> string(21) "Status: 404 Not Found" }
On my host there is no output. I can't seem to generate anything but a blank page regardless of what content is echoed by PHP, or included below as normal HTML, though PHP processing e.g. logging, database writes etc continue as normal.
Can anyone suggest what the problem might be or how to resolve it?
'blank page' smells like error_reporting(0) hiding the error messages you would get. Maybe there is some output before your headers and that raises an error. Check that.
If PHP is configured at your host to run through CGI, it may be impossible to generate 404 error pages in IIS (except by lying and returning 200 OK, which is a Bad Thing). Certainly I've been unable to persuade IIS 4-6.0 to allow my CGI 404 errors through to browsers.
You generally don't want PHP to run CGI anyway, there are other related problems as well as it being slow. On IIS, the PHP ISAPI extension should be preferred (though as I've not tried it I can't confirm it solves this specific problem).
What if you put text after the PHP tags?
Also, make sure your script isn't erroring out on your host, whether checking apache error logs, running php -l on your script or turning error_reporting on and display_errors on.
I have the same problem with PHP 5.2.6 on Linux. I find that the first 8109 bytes are not printed by the web server.
IE6 ignores custom error pages < 512 bytes in length. This could be an explanation for this problem, but probably you have tested in more than one browser anyway.
Check that your host allows you to change headers on the fly with PHP. My host doesn't allow me to set the 404 header through PHP, though other headers (301, content-type) are fine.
My advice is to not set the HTTP/1.1 404 header yourself and let the web server do it for you.
Traditionally, this is done through the Status header, which the web server should take and turn into an HTTP/1.0 or 1.1 404 Not Found header.
(Side Note: The Status header is not a real HTTP header and is used solely to communicate information from an app to the server itself.)