homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

HTACCESS changes being ignored
I reupload and nothing changes

 10:49 am on Aug 19, 2010 (gmt 0)

I make changes to my HTACCESS, upload it... and nothing has changed on the site.

In fact, I can replace the entire contents of the file with jargon and it will still not notice any changes.

No idea why the file is not being refreshed.



 11:18 am on Aug 19, 2010 (gmt 0)

Hi there migthegreek,

Your putting this file into the root of your server I hope, and you are just calling it .htaccess?

Been a while since I last set up apache, but I'm sure you have to have the module enabled to use htaccess.



 11:46 am on Aug 19, 2010 (gmt 0)

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?


 11:54 am on Aug 19, 2010 (gmt 0)

Hi there migthegreek,

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.



 12:33 pm on Aug 19, 2010 (gmt 0)

I have everything visible.

This is driving me INSANE. It is behaving even stranger now. I have completely emptied the htaccess yet it is still redirecting my requests, which was a rule I had in about 20 minutes ago.

However, if I put jargon into the htaccess, it breaks - meaning it is recognising the changes. But where the hell is it getting this redirect rule from?


 12:36 pm on Aug 19, 2010 (gmt 0)

OK, I have now DELETED the htaccess off the server, and it is still redirecting.

How is this even possible?

Edit: It's Firefox's cache. If I clear the cache, the changes appear. I don't really understand how Firefox is caching the htaccess though.


 1:04 pm on Aug 19, 2010 (gmt 0)

Hi there migthegreek,

If the contents of the .htaccess file isn't too huge, post in the apache forum, and someone in there can better advise you. [webmasterworld.com ]

It sounds to me like the information has been cached somewhere - but .htaccess isn't my strongsuite I can't really advise too much..

[EDIT]: Ctrl + F5 is always advised when doing css or .htaccess changes - glad your good now



 5:35 pm on Aug 19, 2010 (gmt 0)

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.


 6:49 pm on Aug 19, 2010 (gmt 0)

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

More to the point, all browsers will cache all pages, images, css, and JavaScripts --any requested objects, in fact-- unless you control this caching behaviour. The browser also caches redirect and error responses associated with those objects, unless you control this caching behaviour.

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



 9:14 am on Aug 20, 2010 (gmt 0)

Thanks guys. Just some points in response:

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.


 9:00 pm on Aug 20, 2010 (gmt 0)

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.



 11:38 pm on Aug 20, 2010 (gmt 0)

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.


 9:44 am on Aug 26, 2010 (gmt 0)

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:

  1. Last night at home, site displaying but not working.
  2. This morning at work, site displaying but not working.
  3. Made some changes, site displaying but not working.
  4. Revert changes back to original from last night.
  5. At this point, all changes to htaccess are being instantly recognised.
  6. Make some changes, something half decides to work.
  7. Make changes - 500 Internal Server Error.
  8. Revert changes back to original from last night - 500 Internal Server Error.
  9. Revert changes to 3 steps above - 500 Internal Server Error.
  10. Revert changes back to original from last night - 500 Internal Server Error.
  11. Revert changes to 5 steps above - 500 Internal Server Error.
  12. 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).

Global Options:
 top home search open messages active posts  

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved