I was doing some tests with mod_rewrite in my wamp environment.
I tested a simple rule that I put at the root of one of my websites and asked it to redirect any request ending with index.php to localhost (there is no sense to it, just wanted to check the rule)
It worked, but after, any change I'd made to my .htaccess file rule was not reflected.
After a while I just decided to delete the .htaccess... well it's still doing redirection! I just don't understand it. Does Apache cache the rules or something (restarting services trough wamp menu didn't change anything)
(Don't ask for the exact rule I used, since I deleted the file, I don't think it's relevant anyway)
.htaccess files are processed each time a request comes through. It is possible that your browser cached the request being forwarded. Did you try it with httpfox or anything to see what the headers said?
Have you tried deleting the browser cache?
Related
I have the following very simple htaccess file:
RewriteEngine On
RewriteRule a.jpg b.jpg
RewriteRule c.php d.php
All four resources are in the root folder.
The PHP rule works as expected, however, the JPG rule is just ignored as if it were not there. The image a.jpg continues to display.
I am completely clueless on why that would happen.
The only explanation I could think of is that Apache is somehow configured not to INVOKE htaccess at all if the requested resource is an image. Is that even possible?
I found out the reason and I am posting my answer in case anyone faces the same issue.
It appears that both Nginx and Apache are configured on the server. Nginx is internet facing and Apache is internal.
It appears that the web hosting company has done so to benefit from Nginx's better performance and to provide compatibility to anyone coming from Apache environment at the same time.
When Nginx receives a PHP request from the internet it allows the request to pass through and reach Apache but when the resource is a static resource (image, css, js) Nginx delivers the resource itself for optimum performance.
The htaccess image rule above is not processed because the request is not even reaching Apache.
I temporarily solved the problem by not allowing Nginx to handle the images itself and allowing them to proceed to Apache.
The better solution of course is to remove htaccess dependency and handle everything within Nginx configuration file, which I will be doing soon.
The best solution of course is to remove Apache completely but it is a shared server and I don't have full control.
I am testing some basic .htaccess rewriterules and I am pretty sure that even after deleting a rule in .htaccess and saving the document, apache ignores it and acts like the rule was still there (only for earlier requested sites) - even after apache restart. It is driving me crazy, the behavior is really mad. Is there any apache cache which is about to be cleaned or the problem is elsewhere?
It's madness! Not really, it's just annoying.
When you set a redirect in Apache what you're doing is actually configuring headers that are passed to your browser. Your browser keeps a cache of 301 and 302 redirect headers (and other things like DNS) in the event you go back to those pages, so it can save you time. 301 redirects are supposed to be permanent (that's what you're indicating), so if there is no need for the browser to do something like perform a DNS lookup or visit a page based on a redirect, then it will cut corners and use the cache in order to provide you with a faster browsing experience.
You need to flush your browser's cache to prevent the store redirects from happening.
Additionally, you'll want to resubmit your page to Google (in the event it's on the web) in case they've crawled your site while the invalid headers existed.
I have added url rewrite rules to my .htaccess file. Should I see these changes working right away?
Changes to .htaccess are immediate and do not require a restart. Normally, if you aren't seeing what you expect from .htaccess changes, you have a syntax error and should check Apache's logs for some idea of what's going on.
If you use redirect 301, clear browser cache.
NVM found it.
The .htaccess files follow the same syntax as the main configuration
files. Since .htaccess files are read on every request, changes made
in these files take immediate effect.
Apparently, some servers only check .htaccess files periodically. I've found this to be the case w/ our AWS host.
My source is only a comment below the answer here, but it matches my experiences and others seem to agree.
I've done everything right. My server has mod_rewrite enabled, my virtualhost path has AllowOverride set to All, and I have the .htaccess file in place with the rewrite rules same as everyone. But I have trouble accessing some pages using their clean url paths. So for 90% of the pages, clean urls work fine. But for that 10%, they don't.
I have checked whether those pages exist -- they do. Checked whether they are accessible using index.php?q=[path] -- and they are. They are only inaccessible through clean url paths.
Can anyone help me with this mystery?
Because you can access your pages through q=path/to/menu/item, then it's clear that it is mod_rewrite that is at fault and not Drupal.
To debug what is going on with your rewrite, either turn on the rewrite log and tail -f it while you request the troubled pages, or alternatively print_r($_GET) at the top of index.php or page.tpl.php to see what is actually being requested.
If you are comfortable posting your potentially sensitive .htaccess here, do so and we can have a look at it for you to see if there are any misconfigurations.
mod_rewrite has a few long-standing bugs that mangle URLs on the way through (do your problem urls have any escape characters?). I don't know if Drupal does this, but in other PHP apps I have had to add code to re-do the rewrite once the correct entrypoint has been reached.
Unfortunately, Drupal can't take its search path in PATH_INFO (as a lot of other apps do), otherwise you could use mod_alias which is much simpler and much more reliable.
Because of weird security policies of my hosting provider I have to define my rewrite rules in /etc/apache2/conf.d/examplesite.conf instead of writing them on an .htaccess on the www folder of that site.
What I'm trying to do is setup a Wordpress Mu server (http://mu.wordpress.org/forums/topic/17349 ) and so far its working on a 50%.
The main blog loads perfectly but other sub blogs (located for example at www.example.com/blog2 ) don't.
I'm guessing the problem is that the rewrite rules behave differently when declared at .conf files for each virtual host instead of using .htaccess files.
Has anybody else had this problem? How can you fix it?
This doesn't sound like a rewrite problem to me but maybe it is. You don't say what the error is when you try to load one of the sub blogs. Perhaps posting up what your rewrite rule is would be helpful. Also would you be able to set up a scenario where you did them in .htaccess files on a localhost or something and seeing if there was a difference?
If pretty permalinks work, then mod_rewrite is enabled, and rewriting URLs to WordPress successfully.
If this is the case, then it's a problem with your MU install.
Did you choose paths over sub-domains during the MU install? If you didn't, but then later switched, that's where the problem is - are you in a position to fresh install?