I am about to learn rewrite rules on lighttpd.
I have a question: is this the normal state of the art that lighttpd is ignoring the .htaccess files ?
I have some rules in .htaccess and they where ignored, when I write them to the lighttpd.conf they are executed correctly.
how can I enable mod rewrite to read the .htaccess files ?
Quoting Lighttpd FAQ:
Do you support .htaccess files?
No. Lighty's design does not permit implementing this functionality as config files are loaded at startup time and .htaccess would be needed to be parsed at request time.
[…]
Furthermore, .htaccess files are Apache config files. We would need to write a parser and it might not even be possible to map all functionality to lighty logic.
Related
I was starting to implement mod_rewrite rules on my site when I came across some weird behaviour. I removed my htaccess file for this test, to take it out of the equation.
My local dev site is at http://dev.mydomain.com and is a virtual host.
If I go to, eg "http://dev.mydomain.com/blog/", that folder doesn't exist, but apache finds a matching php file "blog.php" and instead displays that.
This only happens when there is a matching php file - when there isn't, eg "http://dev.mydomain.com/barfblurg/" I just get a 404.
It's like there are some extra mod_rewrites going on above where the site htaccess would be - that when /file/ couldn't be resolved, it searches for other matching files and instead serves this - but there are no other htaccess files that would have an effect, so this must presumably be a config thing? I can't see anything in the apache.conf or php.ini that would cause this behaviour.
(This also doesn't happen on my live host elsewhere, so it's definitely a config thing.)
Anyone point me to where to turn that behaviour off, because it's interfering with the url rewrites I want to do?
(Apache2, OSX, 10.10.5)
This behavior is due to enabling of option MultiViews.
Option MultiViews is used by Apache's content negotiation module that runs before mod_rewrite and makes Apache server match extensions of files. So /file can be in URL but it will serve /file.php.
To turn this off use:
Options -MultiViews
at top of your .htaccess or in Apache config/vhost file.
Right now all my mod_rewrite related statements are in my VHost configuration files. I would like to move the common ones into my apache configuration file. However, when I move either of these two statements
RewriteEngine on
RewriteMap domainMapper prg:foo/bar.php
The website breaks. A look at the mod_rewrite documents indicates that the RewriteMap directive should work in both the server config and the virtual host context. However, this is not the case. Can someone clarify whether I am doing something wrong, or failing to do something necessary?
You can put rewrites outside of the VirtualHost entries. However, the rewrites have to be pulled into the virtual host context because that's where your URLs are being processed. You must set
RewriteEngine on # turn on rewrites in this vhost
RewriteOptions Inherit # inherit rules from outside scope
in each VirtualHost where these outside rewrites are to be active. The enabling of the engine is not inherited, so the Inherit is not enough by itself.
For more info, see the documentation:
http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewriteoptions
I've noticed that on several web pages e.g. StackOverflow instead of stackoverflow.com/questions/ask.php they have stackoverflow.com/questions/ask.
How is this done?
If I understand your question right, you just want to have file-names|tags|titles|categories after the last slash to route semantically to the according file or a hidden path;
If so, you will gain this dependent on the possibilities you have:
A) Do you have access to httpd.conf on your Server?
Look out for the DirectoryIndex;
OR
B) If you are not able to edit httpd.conf, do you have access to .htaccess on your server?
Look out if DirectoryIndex is already set anywhere, in most cases it won't; so you want to create your own new entry;
TODO:
Now define the DirectoryIndex by letting this reserved word be followed by the filenames you want to have
been routed to another filename or path/filename
GODO:
DirectoryIndex
[SPACE]
file-name.ending OR file-name OR tag OR title-with-some-words-bond-together
[SPACE]
repeat step 3 and 4 until you have a set of catchers to be caught ...
at least: add the target of your set by spending a path
DOJO:
RELOAD your server
OR
RESTART if necessary
EXAM:
DirectoryIndex index.html index.htm index.pl index.asp index.jsp index /routed/to-path_of/index.php
DirectoryIndex ask ask.php
MOJO:
This is a quant of what you can achieve; Look out for pretty-printing URL's, apache mod-rewrite, DirectoryIndex, URI URL hiding, domain forwarding and similar keys you can google for.
In most cases it would have been realized by well-known BLOG/CMS-SoftWare like WordPress, JOOMLA, DruPal, etc. via mod-rewrite, as this is the controlled and preset way if necessary rights are given.
Personally i would recommend to use the simple format of setting DirectoryIndex via .htaccess, as i explained before, because if you realize your own magic-words you may want to write a script that checks for hash-changes, sniffs history and responds accordingly to server-errors.
If you program it in DJango, NodeJS, or other WebApp language, they actually parse the URL and do not give you files. Instead it is known as views and map into a certain piece of code.
I suggest your learn NodeJS.
It is done through a .htaccess file...
I noticed Joomla, Wordpress and other CMSs have blank index.html files in ALL their sub folders to prevent people from peeking into the folder structure. My question is why can't they forbid folder viewing using the .htaccess file instead of putting a blank index.html file into all the folders. What's the difference and why have they chosen index.html?
Turning off folder 'Indexes' is best done in the master httpd.conf or vhosts.conf file rather than local .htaccess files.
Joomla (and Mambo before it) have been around quite a while and are used widely on shared hosting servers. The decision was taken to use index.html files as a safe fallback given the 'mixed' nature of shared hosting. Obviously .htaccess files are apache only, can cause server 500 errors if present on servers not expecting them or if they contain directives not supported by certain server setups. Consequently by default Joomla doesn't ship with a .htaccess file as such. There is a htaccess.txt file which the user needs to put in place manually if they activate certain features. It is assumed that a user knowledgeable enough to put the file in place will understand the consequences and if it does kill their site they will immediately understand the cause - due to the error immediately following their actions.
As server setups have advanced there is (sometimes heated) discussion about the current validity of the use of index.html files - but for now the policy is that all add-ons should ship with 'blank' index.html files in all folders.
in a product I'm fighting with, I found an .htaccess file at the application root, which basically rewrites requests to non-existing files to a central processing script.
For performance reasons I now want to move that rule to my server (virtual host) configuration.
The simplest way to do it is to literally copy the rules into a <Directory> section, as these get interpreted just like .htaccess contexts, right? Well - it works.
Would I have any benefit from modifying the rules and moving them to server/toplevel context instead of a directory context?
EDIT: I seem to not have been clear enough. By 'directory context' I do NOT mean a .htaccess file, but a <Directory> section within my server configuration file.
Here's an interesting blog post about that:
http://www.fubra.com/blog/2008/01/htaccess-vs-httpdconf/
Seems they concluded that it's only about 6.6% faster to have the rules in httpd.conf
So you get a bit of a performance gain, but you also give up some flexibility to change rules per directory or without restarting the server.
The server configuration file is only read and parsed once when the server is started. But .htaccess files read and parsed every time a request is done. Furthermore any .htaccess file on the way down to the directory where the requested file is located are read an parsed. If you have a structure like this:
htdocs/
foo/
.htaccess
bar/
.htaccess
baz/
.htaccess
somefile.html
And you would request /foo/bar/baz/somefile.html, all the .htaccess files the file hierarchy down to somefile.html are parsed and parsed. Now you can imagine on your own if that’s an overhead or not.