I am building a very simple page here: http://www.wordjackpot.com
My problem appears in Google Chrome only, when I reload the page, the images are reloaded each time as if there's no cache, I'm not sure if the problem comes from my code or from chrome because for the example on stackoverflow.com images have http code 304 when I reload the page.
Then my question is: what am I doing wrong ?
Thanks.
These are your return headers... you are explicitly telling the browsers to not cache.
This will be an apache (web server) setting.
Accept-Ranges:bytes
Accept-Ranges:bytes
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:keep-alive
Content-Length:4026
Content-Type:image/png
Date:Tue, 03 Feb 2015 14:33:44 GMT
Pragma:no-cache
Server:Apache
Set-Cookie:300gp=R3396092545; path=/; expires=Tue, 03-Feb-2015 15:46:10 GMT
X-Cacheable:Not cacheable: no-cache
X-Geo:varn34.rbx5
X-Geo-Port:1011
X-Pad:avoid browser bug
Look at your HTTP Headers, you have no-cache all over it.
Related
I realise that this might be a VERY obscure question but it's driving me mad, I have 5 extra characters being inserted into the URL while navigating between the pages on my site. (eg. http://track.chhs.nsw.edu.au/UXTWP/userAccount.php?) The UXTWP is being added and I'm not sure where from but it is breaking the navigation randomly.
The site is hosted on goDaddy.
It contains HTML CSS PHP JavaScript and mySQL.
Everything was working well until I added a "fix" in PHP to stop a potential 'hack' that would use an id being passed in the URL to switch the viewed content.
I'm not sure this was the problem but that was the most recent change before the errors started occurring.
this is the site I also looked to place the code up on phpfiddle but I'm not sure what to add?
if(isset($_GET['a'])){
if(strpos($userRow['sID'], $_GET['a']) !== false) {
$_SESSION['student']=$_GET['a'];
$tempArray = db_select("SELECT * FROM student WHERE sID ='".$_SESSION['student']."'");
$studentRow = array_shift($tempArray);
$_SESSION['impactTool'] =$studentRow['impactAssToolID'];
$SName = $studentRow['sName'];
$SDOB = $studentRow['dob'];
$SFormDate = $studentRow['formDate'];
$prevInf = $studentRow['prevInfo'];
$famInf = $studentRow['famInfo'];
$contInf = $studentRow['contextInfo'];
$impactIDMsg = "?z=".$_SESSION['impactTool'];
$btnFlag = true;
}else{
header("Location:logout.php");
}
The intention is to dump the user back to the login screen via logout if they attempt to access a student's detail that doesn't belong to them.
Thanks in advance for any help provided.
Ok this time I think it is fixed!! Thank you so much #Progrock for your persistent testing and ideas.
The fix:
I have included a blank .htaccess file into the root of the site.
Now I can navigate through the different pages using the onsite navigation and the browser navigation and I can't create the error anymore.
I'm hoping that this is a permanent fix and my best guess is that it was the browser/server looking for the .htaccess file on particular triggers when not finding it looking to the server generic .htaccess file.
Hope this post helps someone in the future experiencing a similar problem.
Not an answer, but an observation:
I finally experienced the bug when using curl to view headers:
curl -I http://track.chhs.nsw.edu.au
Output:
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /TSXbZ/
Then shortly after, the same curl call resulted in the desired page without the redirect. So the bug is inconsistent, as you have said.
If I do a header location redirect in Php code. Or I use a .htaccess rule to do something similar: A return header reads something like this:
Server: Apache/2.2.22 (Foo)
The absence of an apache server header (for some of your responses) makes me suspicious that a proxy or caching layer may sit in front of your webserver and Php code.
Reading your code, I can't see any obvious reasons for the character insertions.
Notice subsequent differences with the following responses (return headers):
3:21% curl -I http://track.chhs.nsw.edu.au
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /XRjRZ/
3:23% curl -I http://track.chhs.nsw.edu.au
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /
3:24% curl -I http://track.chhs.nsw.edu.au
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /
3:24% curl -I http://track.chhs.nsw.edu.au/index.php
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /index.php
3:24% curl -I http://track.chhs.nsw.edu.au/index.php
HTTP/1.1 200 OK
Date: Fri, 02 Dec 2016 15:24:56 GMT
Server: Apache/2.4.23
X-Powered-By: PHP/5.4.45
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=60d307bdc288bf1371dc5e0c8c397cdf; path=/
Vary: User-Agent
Content-Type: text/html
Have you got an esoteric .htaccess, or server config?
I'm the sole developer building a LAMP web application for a small infancy-stage startup and have been crying myself to sleep over a bug that only occurs when using the web app in Internet Explorer 10-11 and Edge (Chrome, FF, and Opera work like a charm). Worse yet, it happens randomly and about 50% of the time after a user has authenticated and logged into the web app. Here's a screenshot:
Here's what shows up in the DOM Explorer when inspecting:
15447HTTP/1.1 200 OK
Date: Wed, 17 Aug 2016 09:27:27 GMT
Server: Apache/2.4.12 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 4972
Keep-Alive: timeout=15, max=97
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
‹í]ëvÛ¶²þÝ<ʶGöÙÖÅò-±-u9²8©/µ¤mVVDBlŠdJ²Òößy’ýo¿Æy”ó$gðŠÔ
l÷ê^‹j‹¸|33`$}zݹÿùæ
‚¡Ý~vý!Øj?Cð:’CnàUÉç·ÓuâÕ`ê…O-# OAW?BæûŒw÷çÕç†Šå£ —d4°IûÄSæú/©õÿóÏãºLTêz¾ë?˜¶
º.ö9IËS2ñ\?PŠO¨ZS“TÅâ
(¶«ÌÄ6imóÚÿSõÝIµã=ÐnŠ‰‹³±ú$‡<
®¯Í)ÓwݾMªŒ¤:&>íQ(¸ŽRë`ûm÷Ç;ëf·7ö¼ó÷¿ü8=øùËã®Îß¿ï¼ß}8MN'ýæ¥ê!
Ë`ÁÔ&l#ˆ‚÷^Øi&cø¤}ËXÝqý!¶éRãš ÒíÙã¡KŠ(TáÂëõˆ‡Õ¤ø°GYÍt‡ìûR{Úºöˆó;ì
k·Ñ¨6*ÉF%b£2Ër…A÷æ(#:£2P§Ã~Ývûn
R+\à²Ú×Õ*úÁÅz%xB'¶§5ªVCdfúÔäB½‘cò¾Þ [lËÝêoù[xk¸ùýX‘1Äu÷˜AåSË?¢ýO-þÏï¿Çõ7!
~ÿýã§Íš7bƒ
<more garbled text>
As one can see from the response headers, the server returned a status of 200, and there are no errors or warnings in the console. Under the 'Network' tab, everything appears to have returned with either 200 or 302, with the exception of a couple 404s when retrieving profile pictures from the LinkedIn REST API (the pics still show up though in the other 50% of the time that the page actually displays properly...). On the server side, there is nothing in the Apache error log, and syslog is clean. The actual content appears to be compressed, which shouldn't be a problem given that the server is specifying the content encoding as gzip. Either that, or I'm looking at encrypted content.
I'm running Apache 2.4.12 on Ubuntu 15.10. Content is (of course) served over HTTPS, and the cert doesn't expire for another year. The application is written in PHP, and this happens on both the staging and production servers. I've scoured SO, Serverfault, and Google for a similar problem but haven't been successful. If anyone has encountered this error before or has any possible idea as to what's going on, any help would be greatly appreciated.
What is the definitive solution for avoid any kind of caching of http data? We can modify the client as well as the server - so I think we can split the task between client and the server.
Client can append to each request a random parameter http://URL/path?rand=6372637263 – My feeling is that using only this way it is not working 100% - might be there are some intelligent proxies, which can detect that… On the other side I think that if the URL is different from the previous one, the proxy cannot simply decide to send back some cached response.
On server can control a bunch of HTTP headers:
Expires: Tue, 03 Jul 2001 06:00:00 GMT
Last-Modified: {now} GMT
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Any comments to this, what is the best approach?
Server-side cache control headers should look like:
Expires: Tue, 03 Jul 2001 06:00:00 GMT
Last-Modified: {now} GMT
Cache-Control: max-age=0, no-cache, must-revalidate, proxy-revalidate
Avoid rewriting URLs on the client because it pollutes caches, and causes other weird semantic issues. Furthermore:
Use one Cache-Control header (see rfc 2616) because behaviour with multiple entries is undefined. Also the MSIE specific entries in the second cache-control are at best redundant.
no-store is about data security. (it only means don't write this to disk - caches are still allowed to store the response in memory).
Pragma: no-cache is meaningless in a server response - it's a request header meaning that any caches receiving the request must forward it to the origin.
Using both Expires (http/1.0) and cache-control (http/1.1) is not redundant since proxies exist that only speak http/1.0, or will downgrade the protocol.
Technically, the last modified header is redundant in light of no-cache, but it's a good idea to leave it in there.
Some browsers will ignore subsequent directives in a cache-control header after they come across one they don't recognise - so put the important stuff first.
Adding header
Cache-control: private
guarantees, that gataway cache won't cache such request.
I'd like to recommend you Fabien Potencier lecture about caching: http://www.slideshare.net/fabpot/caching-on-the-edge
To disable the cache, you should use
Expires: 0
Or
Cache-Control: no-store
If you use one then should not use other one.
I am going a little crazy here trying to find a solution to something that is probably pretty straight forward.
I have a group of reports on an intranet (not accesible to the outside world) and each report has an input form that has a bunch of HTML inputs that vary the report data.
Problem being when you hit back to the form from the report the form is reset to it's original state. I want it to cache (remember the HTML input variables) and all I can find is how to turn caching off, I want it on! I would prefer not to do this with $_SESSION and $_COOKIE storing as I have 120 reports with roughly 10 or so inputs each, so its going to take forever to store everyone of them and re-load variables on refresh.
I am not the server administrator, but I beleive we are running Apache 2.2 web server. These are all PHP/HTML based pages. Any advice would be great!
It is not to do with my Browser as other forms are being cached. I am more looking into what modules on the server need to be activated to allow caching and what notes I should put in the header of the forms to allow caching. The intranet runs through a proxy so I am thinking I will need cache-control to be public.
EDIT:
When I run the form page, the HTTP headers show me this which I feel should be changed:
(under Response Headers)
X-Powered-By: PHP/5.3.3
Via: *[REMOVED]*
Server: Apache/2.2.3 (Red Hat)
Proxy-Connection: Keep-Alive
Pragma: no-cache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Date: Wed, 13 Feb 2013 23:33:32 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 5191
Connection: Keep-Alive
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
I have a feeling I need to change the Cache-Control and Pragma values. Anyone know how to acheive this?
trying adding these headers to the top of the page:
header("Cache-Control: private, max-age=10800, pre-check=10800");
header("Pragma: private");
header("Expires: " . date(DATE_RFC822,strtotime("+2 day")));
NOTE: if the form submits and post data to a second page, you may want to put it at the top of both pages. also, make sure the code is after any session_start(); if you are using sessions.
Try setting the autocomplete attribute of the inputs to on.
<input name="myinput" autocomplete="on" type="text">
I'm trying to use early flush with php5/apache2 to execute some code, render some json and after that executing another part of the code that take several second but doesn't produce any response.
The basic code so far is:
#apache_setenv('no-gzip', 1);
#ini_set('zlib.output_compression', 0);
echo 'Page loading'; // code to render;
ob_flush();
flush();
sleep(29); // LONG time code to execute
The previous example does not work. I mean it will echo 'Page loading' after 29seconds.
If I looked at the http response I have:
(Status-Line) HTTP/1.1 200 OK
Date Mon, 04 Jul 2011 19:49:19 GMT
Server Apache/2.2.11 (Win32) mod_ssl/2.2.11 OpenSSL/0.9.8k PHP/5.3.0
X-Powered-By PHP/5.3.0
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
Keep-Alive timeout=5, max=100
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html
My problem is not really why it doesnt work? but How can I checked where my string get buffered?
I know that there is different buffer:
- php output_buffer, php zlib.buffer
- apache mode_deflate / gzip
- browser buffering
All php output buffering are off, apache mode_deflate is activated but as you can see the transfer-encoding is "chunked".
I have no idea how to find out where is my problem, I'm using HttpFox to see the header and I try to get the content of the HTTP request, HttpFox say that the content is not ready until the 29seconds are done.
Any advice?
Hmm have you tried ob_get_level() ?
Marc B was right...
I had to make a loop of a 1000, with output_buffering activated
$var = 1000;
while(--$var)
echo 'Page loading'; // code to render;
To be able to see result before the sleep.
I have to to a loop of 100, with output_buffering = off to get the same result.