How long does it take from uploading ftp for it to show http?

Question

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.

I 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.

Solution 1

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

Solution 2

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.

Solution 3

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.

Solution 4

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.

View more solutions