In my localhost PHP file test.php, I use php function file_get_contents to grab a forum index page.
echo file_get_contents('http://www.XX.com/forum.php');
when the forum data, sunch as posting , member changes, I refresh the test.php, content is hasn't changed, I want to know why?
There are a number of possible reasons:
You are behind a caching proxy server and are receiving a cached copy of the page
This can exist at the network or server level
The target site detects such requests and provides cached versions for performance or security reasons
Your browser has cached the output of your script.
You will need to examine your configuration, talk to your network administrator, or check your own browser's cache to find the source of the problem.
Related
I have a website where the client search a term and results are retrieved through an ajax request. On php side, the called script check the date of the cache (cache are files) and if it's older than an established time it refreshes the results, else it return the cache file content: die(file_get_contents($cache_path));
The cache time is a few hours, an to refresh it takes just a few seconds, so the greatest part of the requests will end up in cache response.
So I thought that using header("location: $cache_path"); would be less stressful for the server, because it simply tells the browser to get the contents from the cache file without passing it through the script.
The downside is that the cache file path would become public (which is not biggest problem ever, because the content is the same), but, you know, it's never good to give the resources locations...
So, performance wise, is there a big difference between file_get_contents and redirecting? The average cache file size is 120kb... Any other ideas and suggestions?
You can use "internal redirect": through X-Accel-Redirect header for nginx or X-Sendfile for Apache. In this case you don't show any additional URLs to a client and don't deal with cache files in you script.
For configuration details you can read an official documentation or, of course, other SO questions (like this one).
When I'm coding HTML and CSS and load the page in the browser to check changes, sometimes it doesn't update for a while. This obviously causes problems with incremental changes where it's hard to tell if it's changed to suit my latest change or not.
I was wondering if there was a way around this? Possibly a browser (or mode) which is especially for this situation that doesn't have this behaviour?
Try Ctrl+F5 on Windows or Cmd+Shift+R on OSX, this will avoid your browser reading its cache when loading the page (at least when it's Chrome or Firefox)
You could try deleting your browser cache and reloading the page.
In case of CSS I also found sometimes I will need to load the CSS file separately in my browser and refresh it to update.
Sounds like your browser cache, you can test this by clearing it or doing a "hard refresh" to confirm.
You will need to throw some no cache headers if you want to stop this permanently, you can do this from the web server or server-side code depending on your setup (see How to control web page caching, across all browsers?)
On windows refresh with CTRL + F5. The browser will not show from cache. Also in developer tools you can tell it not load from cache
It is mostly because of browser cache.
Just a suggestion(You may find it useful, As an addition to other answers):
If you are on chrome then there is an option to disable cache while the dev toolbar is open. It works for me to ensure there is no caching while I am developing. (I keep my dev toolbar open all the time while developing so it works for me), Here is the screen shot.
Quote from chrome dev tools (https://developers.google.com/chrome-developer-tools/docs/settings)
General
Disable cache Will prevent the caching of resources ONLY for pages
which have DevTools open. This will not disable caching if the
DevTools are closed
.
Hmm could be a web server setting, caching request to your same resource. I used to see that a lot on tomcat with JSP. With tomcat we used to delete compiled classes ('work' folder), though, in your case with PHP you may check your server cache settings (files/sessions).
Example: "A typical web server, such as Apache, uses the time of file modification to inform a web browser of a requested page’s age, allowing the browser to take appropriate caching action. With dynamic web pages, the actual PHP script may change only occasionally; meanwhile, the content it displays, which is often fetched from a database, will change frequently."
Source : http://www.sitepoint.com/caching-php-performance/
Another workaround would be to touch (add a space and save) your PHP file when you want it to reload.
I'm trying to stream MP4 files through Apache / Nginx using a PHP proxy for authentication. I've implemented byte-ranges to stream for iOS as outlined here: http://mobiforge.com/developing/story/content-delivery-mobile-devices. This works perfectly fine in Chrome and Safari but.... the really odd thing is that if I monitor the server requests to the php page, three of them occur per page load in a browser. Here's a screen shot of Chrome's inspector (going directly to the PHP proxy page):
As you can see, the first one gets canceled, the second remains pending, and the third works. Again, the file plays in the browser. I've tried alternate methods of reading the file (readfile, fgets, fread, etc) with the same results. What is causing these three requests and how can I get a single working request?
The first request is for the first range of bytes, preloading the file. The browser cancels the request once it has downloaded the specified amount.
The second one I'm not sure about...
The third one is when you actually start playing the media file, it requests and downloads the full thing.
Not sure whether this answers your question, but serving large binary files with PHP isn't the right thing to do.
It's better to let PHP handle authentication only and pass the file reference to the web server to serve, freeing up resources.
See also: Caching HTTP responses when they are dynamically created by PHP
It describes in more detail what I would recommend to do.
Is there any way to save a external web page to folder on server but with all webpage elements (JS files,images,css... etc.). Like you can do at browser with option save-complete-page but I need this to save with php on my server folder. And when include this folder to show the page as original. Maybe with curl or some php function ... ???
HOW TO DO THAT. please HELP!
p.s.I doing this for good reason not for stealing content!
and when I finising with operation and function I will empty the folder.
Are you saying that you want to visit a php site as a client (whether in a browser or via wget/curl/etc) and then save all related server-side files?
Without access to the server, that is not possible. The server-side content (e.g. the PHP pages and possibly some other parts of the site) are interpretted by the server before you as a client see any part of the site. You need server-side access to the files in order to see what is there before the code is interpretted.
So if you have a PHP page, while if someone loads that page they may not see the server side run PHP code; if they grab the source, the file itself is still publicly available, because if you make it not publicly available the person would not be able to load that page.
Thus someone could with the right knowledge 'grab' that file and then read the serverside script stuff.
So is it not safer to make a 'proxy'. for example, AJAX post call to a PHP page (called script handler) and pass a string with the first 2 char being the id to the PHP script to run and the rest of the string being the data for that script, then the script handler runs and include based on the number and returns the echoed back HTML that is then displayed.
What do you guys think? I have done this and it works quite nice, if I grab source all I get is an HTML page with a div container and a javascript file with ajax calls to script handler.
No. Your 'workaround' does not fix the problem, if there ever was one.
If a client (a browser) asks a 'resource' (a page, for example) from a webserver, the webserver won't just serve the resource as it finds it on disk.
If you configured your webserver well, it will know that
An .html, .gif, .png, .css, .js file can just be served as-is.
A .php, .php5, .cgi, .pl file has to be executed first, and the resulting output has to be served.
So with a properly configured server (and most decent webservers are properly configured by default), grabbing the PHP source just by calling the page is impossible - the webserver will know to execute the source and return the result.
But
One of the most encountered bugs when writing your own 'upload/download script' is allowing users to upload/download .php (or other executable) files. If your own script 'serves' the .php file by reading it from disk and writing it to the net, users will be able to see your code.
Solution:
Don't write scripts unless you know what you are doing.
Avoid the not-invented-here syndrome (don't reinvent the wheel unless you are sure you NEED a better wheel AND can MAKE a better wheel)
Don't solve problems that don't exist!
By the by:
if your webserver was mal-configured and is just serving .php files as viewable/downloadable files, your 'solution' of calling it by ajax would not change this... Ajax still is client-side, so any client could bypass the ajax and fetch the script itself.
If your web server is configured correctly, users should never be able to view the actual contents of the PHP file. If they try, they should see the actual output of the PHP script as your web server reads and executes it, then passes that as the response to the HTTP request.
Furthermore, you need to understand that users can easily still look at the file the AJAX request is fetching; all they need to do is install Firebug, or use the Chrome developer tools, and they'll be able to see the full URL the file is fetched from.
So to sum up, firstly you shouldn't need to use this kind of 'security technique' for PHP files, and secondly, the 'security technique' will not stop anyone with more than a passing interest in your data.