I am on a WAMP stack and have the below one line of code for demo.html
<img src="http://localhost/redirect/demo.php"></img>
demo.php code as below
<?php
header("Location: http://localhost/redirect/blah");
exit();
?>
The code works fine. but there is huge response time during content download
when I change demo.html to use script tag vs img tag, there are no problems during response times
<script src="http://localhost/redirect/demo.php"></script>
Not sure why this is happening to IMG tags. Could anyone explain why this is happening and how do I avoid this? Are there any alternate methods to loading IMG via 302 without a javascript solution.
Note - believe this cannot be a PHP/WAMP problem as the response times are not affected when I call http://localhost/redirect/demo.php directly. Trust this has something to do with browser, its rendering, its load events.
If I'm not wrong, scripts are loaded synchronously whereas images are queued and loaded asynchronously.
So my understanding is if you use script tag, browsers wait to load http://localhost/redirect/demo.php which sends 302. This forces browser to execute http://localhost/redirect/blah before loading anything else.
Instead if you use img tag, browsers execute http://localhost/redirect/demo.php and continue to load remaining portion of the page. When demo.php returns 302, http://localhost/redirect/blah gets added to the queue of URLs to be loaded. Because of which the overall time to load the image is more.
Not sure if you can avoid it. Probably, enabling caching on demo.php could help in subsequent requests.
Depending on the usage of your image redirect, you can take a look at URL Rewriting.
I'm not sure it's a good solution because your example code is out of context.
You can also take a look at this question which can provide you additional informations : Is it OK to HTTP redirect images?
Use .htaccess:
RewriteEngine on
RewriteRule ^redirect/demo.php$ /redirect/blah [QSA,L]
Eventualy if you want to have the "blah" file/script on the other server you can use Reverse Proxy see: https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension
Related
using JS : (in <head> tag)
<script>window.location="https://stackoverflow.com";</script>
using PHP : (in <head> tag)
header('Location: https://stackoverflow.com');
end();
Which one I should use ? or another ?
and what about using <meta>?
<meta http-equiv="refresh" content="0;url=https://stackoverflow.com"/>
Many good answers , I don't know which answer I will accept, Thanks so much
The result is same for all options. Redirect.
<meta> in HTML:
Show content of your site, and next redirect user after a few (or 0) seconds.
Don't need JavaScript enabled.
Don't need PHP.
window.location in JS:
Javascript enabled needed.
Don't need PHP.
Show content of your site, and next redirect user after a few (or 0) seconds.
Redirect can be dependent on any conditions if (1 === 1) { window.location.href = 'http://example.com'; }.
header('Location:') in PHP:
Don't need JavaScript enabled.
PHP needed.
Redirect will be executed first, user never see what is after. header() must be the first command in php script, before output any other. If you try output some before header, will receive an Warning: Cannot modify header information - headers already sent
A better way to set the location in JS is via:
window.location.href = 'https://stackoverflow.com';
Whether to use PHP or JS to manage the redirection depends on what your code is doing and how. But if you're in a position to use PHP; that is, if you're going to be using PHP to send some JS code back to the browser that simply tells the browser to go somewhere else, then logic suggests that you should cut out the middle man and tell the browser directly via PHP.
It depends on how and when you want to redirect the user to another page.
If you want to instantly redirect a user to another page without him seeing anything of a site in between, you should use the PHP header redirect method.
If you have a Javascript and some action of the user has to result in him entering another page, that is when you should use window.location.
The meta tag refresh is often used on download sites whenever you see these "Your download should start automatically" messages. You can let the user load a page, wait for a certain amount of time, then redirect him (e.g. to a to-be-downloaded file) without Javascript.
PHP redirects are better if you can as with the JavaScript one you're causing the client to load the page before the redirect, whereas with the PHP one it sends the proper header.
However the PHP shouldn't go in the <head>, it should go before any output is sent to the client, as to do otherwise will cause errors.
Using <meta> tags have the same issue as Javascript in causing the initial page to load before doing the redirect. Server-side redirects are almost always better, if you can use them.
The first case will fail when JS is off. It's also a little bit slower since JS must be parsed first (DOM must be loaded). However JS is safer since the destination doesn't know the referer and your redirect might be tracked (referers aren't reliable in general yet this is something).
You can also use meta refresh tag. It also requires DOM to be loaded.
window.location.href = 'url';
is beter than
header('location:url');
because the header command is mustly return an error "Warning: Cannot modify header information - headers already sent"
using js window.location.href = 'url';
this is beter
I want a url redirect tracer function in the php such as http://www.wheregoes.com/ .
I want to detect four kinds of redirects:
Http 301 redirect
Http 302 redirect
meta tag redirect
javascript redirect
If i use curl, i can easily detect 301, 302 redirect, but it is difficult to detect the other two redirections.
So i want a scriptable web browser, i will use a library as below:
$browser = Browser::createBrowser('chrome');
$delay = 10; // (This is a important parameter for detecting javascript or meta tag redirection).
$browser->load($url, $delay, function onLoadComplete($arr_track_url){
print_r($arr_track_url);
});
I searched and ran into some libraries such as http://www.simpletest.org/en/browser_documentation.html, but they don't support javascript and meta tag redirect.
Is there any php scriptable browser? Or can i detect javascript or meta tag redirection easily?
If I get that right you want to find out where some link finally leads to, if that final url differs from the url actually clicked in the first place?
If so I think the best approach is to let the browser do its work and loko afterwards where it came out. This way you get exactly the 'normal' behaviour of a browser, not that of some library.
Use a (hidden) iframe where you load the url into. Then wait for a window.load event or something and query the documents location afterwards. I didn't try that now, but sounds doable to me...
I use the following code to include page content in a index.php file (template).
if(isset($_GET['page']))
{
include($_GET['page'].'.php');
}
if(isset($_GET['special']))
{
include($_GET['special'].'.php3');
}
The url could look like this: http://www.example.com/?page={PageToShow}
This works fine for Chrome, Firefox and Safari, but the content is not shown in IE 7,8 & 9. Any idea why?
The server side PHP scripts wouldn't be affected by the browser that you use to view the page, so this looks like a rendering issue - check that the included code produces valid HTML, and that you haven't got <html> tags being included within other <html> tags.
You might want to rethink the way you're including page content - doing this via a GET variable is potentially insecure: for a start, it doesn't limit the files to those within the document root of your website.
At the very least I'd recommend doing some sanity checks on the input files (i.e. are they in the webroot?), but a more modern method is to use .htaccess rewriting to send all requests to index.php, where you can then choose which files to include depending on the request (take a look at this post for more information).
The server side script you put above should return the same result with all browsers. Try debugging with $_SERVER["REQUEST_URI"] and see if you get the same results.
Also, I would advise not to use such kind of includes for security reasons.
So I know the general rule of thumb is after doing a header redirect in PHP, you should call exit() to avoid having extra code running, but I want to know if you put code after the redirect header, if it will always run?
I was doing some research on various ways of tracking referrals in Google Analytics and came across this post: Google Analytics Tips & Tricks – Tracking 301 Redirects in Google Analytics
It recommends doing something like this:
<?
Header( “HTTP/1.1 301 Moved Permanently” );
Header( “Location: http://www.new-url.com” );
?>
<script type=”text/javascript”>
var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);
document.write(unescape(“%3Cscript src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));
</script>
<script type=”text/javascript”>
try {
var pageTracker = _gat._getTracker(“UA-YOURPROFILE-ID”);
pageTracker._trackPageview();
} catch(err) {}</script>
From the way I've always understood the header() function, it's up to the browser and it can run the redirect whenever it wants to. So there's no guarantee the JavaScript would actually begin or finish executing prior to the redirect occurring.
PHP's documentation for the header() function indicates the reason for exiting after a redirect is to "make sure that code below does not get executed when we redirect." That doesn't sound like they guarantee all following code will run, just that it could happen.
Regardless, I found a different way to actually manage the tracking, but I wanted to see if I could find out how exactly header() worked in this situation..
Thanks for your help.
Using the header function in PHP only adds to the headers of the response returned by the server. It does not immediately send any data and does not immediately terminate the connection. Any code after the header call will be executed.
In particular, it's a good idea to add a response body even after doing a 301 redirect so that clients that do not support the redirect also get some descriptive response. Infact according to the HTTP 1.1 specification Section 10.3.2 -
Unless the request method was HEAD, the entity of the response SHOULD
contain a short hypertext note with a hyperlink to the new URI(s). If
the 301 status code is received in response to a request other than
GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
It's a race condition. Once the redirect header is sent to the browser, the browser will close the current connection and open a new one for the redirect URL. Until that original connection is closed and Apache shuts down the script, your code will continue to execute as before.
In theory, if there was a sufficiently fast connection between the client/server, and there was no buffering anywhere in the pipeline, issuing the header would cause the script to be terminated immediately. In reality, it can be anywhere between "now" and "never" for the shutdown to be initiated.
The HTML after your Location line doesn't run inside PHP; it would run in the browser. It's up to the browser whether or not to execute the Javascript that you've included on that page; PHP has nothing to do with it.
To me, the PHP docs imply that any PHP below the header() when you send a redirect will continue to run. But it 'runs' in the PHP interpreter, dumping JS to the browser. There's no relation between what it says in the PHP docs and whether or not the JS gets run by the browser.
EDIT:
Well, as Anupam Jain pointed out, looks like that browsers do not terminate connection without getting the response body and it sounds sensible. So i rethinked my answer
That doesn't sound like they guarantee all following code will run
Exactly More likely it's a warning in case there is some sensible code that shouldn't be executed. A private page contents for example. So, beside sending header you have to also make sure that no sensitive content were sent and exit looks like quite robust solution. So, I'd phrase it as "make sure that sensible code below does not get executed when we redirect."
So there's no guarantee the JavaScript would actually begin or finish executing prior to the redirect occurring.
Exactly It seems it has nothing to do with script execution but rather with browser's will to execute anything after getting 3xx response. I think I'm gonna test it, but you can test it as well too.
I have noticed that the code does still execute and multiple headers based on if statements can cause a "redirect loop error". i made it a habit to now add in die("Redirecting..."); after every header redirect and have not see the problem persist.
I'm building a proxy and am trying to deal with a page that uses javascript. The page has a button like this:
<input type="submit" ...cut this out... onclick="javascript:WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions(...cut this out...)) />
When I click this button from my proxy the URL is rewritten to look like this (notice the javascript code inserted here):
http://domain.com/proxy/index-new.php?q=https://proxiedomain.com/javascript:WebForm_DoPostBackWithOptions(new%20WebForm_PostBackOptions(...cut this out...))
I'm not sure how I can handle this in my proxy server. When I don't use a proxy the headers are sent to a completely different page (the URL doesn't include this javascript). Can anyone give me any hints as to what I should look into or read to understand this problem better? From what I understand so far, I need this javascript to be executed (which would require a cient browser).
Any link that points to javascript:... will run JavaScript but not necessarily load a page.
I would leave these links alone, and instead ensure that the form action URL is set to your proxy, and any location.href = 'http://www.example.com/fully_qualified_urls'; are swapped for the proxy URL.
e.g. a simple RegEx replace of "OLD_URL" for "NEW_URL" (accounting for any HTTP vs. HTTPS protocol differences) should suffice for the most part.
Note: I'm aware it isn't "simple", but trying to inspect a javascript: based "link" to modify its behavior will be very awkward.