Yeah, I know how to use htaccess - there is nothing wrong with the setup.
Incidentally it has just started working. I am thinking it's maybe my FTP client (FileZilla). It's like it doesn't refresh the file listings properly sometimes, so you upload it but it's as if it's uploading a cached version or something.
Very strange. I have had this problem a couple of times before, I think. Any ideas on this?
I had something similar a while back, it turned out to be the hidden file option being turned on, set the file listings to display everything, this way you can see everything that is in the root of your webserver.
The only reason this is an issue, is because when you back-up your files and the setting isn't enabled, the .htaccess file will be ignored because the ftp client can't see it.
Once an upload has finished - it should refresh the file list. Try using another ftp client to see if the problem persists.
There are at least three things that can cause this. Probably more.
It could be your hosting service. I have seen this, and it is terribly odd, but when you upload to location A, it's not really location A and takes a few minutes to update to the live site. I've seen it on cheap or free services, don't know what's behind it.
FF is not caching the .htaccess, it's caching the page. If it doesn't recognize it's a new file, it will use the cache. This kinds went away with recent updates but it drove me nuts.
It may not even **be** Firefox. I used to be on satellite Internet which is fine, but it's a proxy server. this means it's your ISP that's doing the caching. And it totally sucks to try and develop in it. You need to use versioning and query strings where you wouldn't have to . . .
Proxy servers are not limited to just satellite, many ISP's use them and is a way of serving up pages faster. Most people don't notice. But for developers it can be a real pain.
Of of all of these, I'm suspecting #3 the most, but as said, there can be many more.
> FF is not caching the .htaccess, it's caching the page. If it doesn't recognize it's a new file, it will use the cache. This kinds went away with recent updates but it drove me nuts.
You can do so by returning proper and appropriate HTTP Cache-Control headers, Etags, etc. along with the requested content. And/or you can use tricks like appending a new/different query string to static-object URLs to force the browser to treat each of your test requests as a new-and-different URL.
Or you can do the simple thing, and simply delete your browser cache after each and every change to your server side code (.htaccess, PHP and PERL scripts, etc.).
An alternative is to completely disable your browser cache during testing (using a check-box or by setting the browser cache size to zero in the browser options). But if you do this latter, then do be sure to re-enable it when you're done testing, or your surfing from then on will be slow!
If you don't use server response headers to control client-side and network caches, then each of these caches will likely retain copies of your objects and the server status responses associated with those objects until such time as those cache entries become the oldest or least-frequently-requested cached objects. If an object is cached, then any request for that object will be returned from the cache, and no request will even be sent to your server. Obviously, this can cause some mysterious-looking behaviour at the user level if that user is unaware of cache configuration and operation.
If you want to see your current Cache-Control headers (and all others), then use the Live HTTP Headers add-on for Firefox and Mozilla-based browsers. This add-on (or something like it) is basic Webmaster kit. I can be used to observe the entire HTTP 'conversation' between your browser as a client and your server while loading a page and all objects included in that page.
On Apache, mod_expires and mod_headers can be used to configure Cache-Control response headers. And if scripts are used to generate and return content, then the scripts can also send cache-control headers.
Until such time as you begin a review and define the cache-controls for all objects on your site, just remember to delete or disable your browser cache while testing...
It must be Firefox, because IE doesn't seem to cache as well and the changes are immediately in effect.
It's also definitely not my hosting or anything like that causing a delay in the files being updated.
I know all about caching, and I have configured cache control in my htaccess as well. My point about caching was that I didn't realise a browser could cache an htaccess file. I know it's a physical file on the server in the public folder, but I didn't think a browser can or will actually download it to cache it (surely it doesn't?). I thought htaccess files just got run on the server side.
A browser certainly does not download or cache .htaccess file. There is no link to your .htaccess file anywhere on the Web (I hope), and if you *allow* your .htaccess file to be fetched via HTTP, that is a rather major security oversight...
While Firefox may use slightly different caching rules than IE, the problem you describe is due to your Firefox browser caching pages, included objects, and server responses. If you delete your browser cache after uploading any new server side code (e.g. scripts or .htaccess files) you won't have this problem. And if you do, it likely means that you workstation has been rootkitted or similarly corrupted, and that something is interfering with the HTTP/TCP/IP stack and messing up Firefox's cache-control.
Since you report that FF and IE behave differently regarding cache-control, I'd say that if this is not intentional on your part, then your cache-control policies (and headers) need to be re-examined.
Firefox wouldn't be caching your .htaccess file (impossible), but it does remember the 301 redirect, and IE doesn't. This is something I first encountered just last week.
For example, if Firefox requests index.htm and it gets a 301 (permanent) redirect to index.php, then the next time you enter index.htm in your browser address bar, Firefox will not even make the request for index.htm. It remembers that the redirect was permanent, and will request index.php from the server, instead. After all, it was told that the redirect is "permanent".
IE doesn't seem to remember redirected results, so it will request index.htm over and over, and get the 301 each time.
Thanks. I knew the notion of the htaccess file being cached by the browser couldn't be possible, but thank you for the reassurance as this was driving me mad.
In any case, I still don't understand. I know there must be some logic to this, but it just appears to be SO random. For example, this is how things have gone today, regarding a different thread of mine:
Last night at home, site displaying but not working.
This morning at work, site displaying but not working.
Made some changes, site displaying but not working.
Revert changes back to original from last night.
At this point, all changes to htaccess are being instantly recognised.
Make some changes, something half decides to work.
Make changes - 500 Internal Server Error.
Revert changes back to original from last night - 500 Internal Server Error.
Revert changes to 3 steps above - 500 Internal Server Error.
Revert changes back to original from last night - 500 Internal Server Error.
Revert changes to 5 steps above - 500 Internal Server Error.
Revert changes back to original from last night - site works perfectly.
And in all these cases, Firefox, IE and Opera behaved exactly the same (FF didn't seem to be doing any extra caching, as before).