How long does it take from uploading ftp for it to show http?
Quick question; I replaced a .css file which I was referencing in html/php that has an absolute address of : http:/www.[my silly domain].com/css/div_image_container.css.
When I access it directly, it gives me an OLDER version of a file I have uploaded into the ftp structure. However, in my main page, using a relative based directory, eg:
<?php
if (condition true){
print("<link rel=\"stylesheet\" type=\"text/css\"
href=\"/css/div_image_container.css\"
MEDIA=screen />");
}
It 'magically' uses the correct, updated script. What is this? Is there somewhat of delay between when I upload through ftp and when my page gets served 'correctly'?
I am using fatcow, and they use sftp, which shouldn't matter.
开发者_如何学CI am just confused. When I access the file through ftp, it is the correct one.
Wait a minute, let me think. FZ has an url copy thing. When I copy a url, it gives something in the form of ftp://[domain name]@ftp.[domain name].com/css/div_image_container.css
When I reference things in html without a http://, is it somehow always executing a ftp? But every user on the planet and beyond would need credentials, or at the very least read privileges.
Any way it's been 30+ minutes and the http:// address for that css file still contains the wrong code.
There is clearly some sort of separation between ftp http, obvious in name, but this is the first time that my assumption that an upload via ftp is reflected, in due time, almost equivalently in 'retrieval' through http has been shaken.
it should be immediate.
add a query string eg
http://example.com/?345678
and it will prevent caching,
double check you are uploading to the correct place, failing that talk to your provider
You are very likely running into a caching problem. It is typical for resources to be cached and served from cache for some period of time before being fetched again from the original source. This is done in order to reduce end-user latency (if it is cached locally, it is much faster than going through several hops, and if it is cached at one hop away, that is still faster than going out three hops to get it).
This is actually a good thing in terms of speeding up web applications, and if you never change a file, you can even set the cache expiration to never, so that it will always be served from cache. In order to force the resource to be fetched, you can set the caching policy to never cache the file (or to a very small amount); however, that will have a latency impact on your users. An alternative, which gives you the best of both worlds, is to never modify the resource at all, set the cache policy to cache indefinitely, add a unique signature onto the name of your resource that you use for versioning, upload your new CSS file with a different signature, and then modify your PHP file to point to the CSS file with the new signature. The change in the resource name will force the resource to be fetched (since the name differs from the one that was cached), but the "cache forever" policy will make subsequent loads fast.
Agree with the caching issue.
A quick and dirty solution is to delete the calling php script (and sometimes related files), call the url from your browser (forcing a 404 error), then re-uploading the script file. It should then be fresh.
I'm also confident it's a caching issue. A simple method to prevent caching is to add a unique parameter on your CSS file name every time. You can make a basic and predictably unique parameter like this:
<?php
if (condition true){
print("<link rel=\"stylesheet\" type=\"text/css\"
href=\"/css/div_image_container.css?" . time() . "\"
MEDIA=screen />");
}
This will append a Unix timestamp to the CSS filename as a parameter, giving a new parameter every second. As long as you don't load the page more often than that, your browser won't hit the cache when it loads the stylesheet.
I know this is an old thread, but I came across it when I was experiencing a similar problem and thought my info might help someone else:
From my fatcow support ticket: "Thank you for contacting us.
It appears to be issue with the varnish cache since we use Varnish Caching technology on our server. The default Varnish Cache time limit is setup as 4 hours on our servers. Thus, your website may not display the changes immediately. For the better performance, I have disabled the cache at: https://www.fatcow.com/controlpanel/cachecontrol/ . "
I'd like to add that I just had the same experience and it was clearly due to the server's caching.
I edited one attribute on my stylesheet manually through FileZilla, then saved it. When I went to the actual live page, nothing changed. Even when when I refreshed the FTP connection and looked at the file, confirming the attribute was 100% there, the page was rendering the old file's output. It just wasn't being reflected on the live site.
Then: Three hours later, I came back to the site, and lo and behold, the page element I added the attribute to has changed.
I'm not a professional (yet), so I can't give much detail in my answer. However, my one source is the specialist who is training me/helping me set our website up. He noted earlier in the process that our hosting provider appears to have very aggressive caching. I can only assume that is the answer for the delay in updating my file.
精彩评论