New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Why doesn't .htaccess work on some control panels?
ServerBachelor
Member
in General
Some panels I've used keep .htaccess in a directory beneath public_html and it works fine, but when I download HestiaCP, I cannot figure out how to give .htaccess a working path. Any advice?
Comments
What is your http server you installed along with HestiaCP?
It might be nginx by default thus .htaccess wouldn't work as .htaccess is Apache thing not nginx thing.
HestiaCP uses Nginx rather than Apache as default, so you can't use .htaccess as standard unless you tell it to not use nginx and to use apache (don't do this, it will break stuff and isn't officially supported).
If you want to do a similar thing in nginx, you need to use directives. Theres a useful tutorial here -> https://www.liquidweb.com/kb/convert-htaccess-rules-nginx-directives/
NGINX configuration
Directives, examples, and 4 mistakes to avoid
https://www.solo.io/topics/nginx/nginx-configuration/
You can install HestiaCP with apache which will enable .htaccess although NGINX has immensely better performance and you can get things to work with some tinkering (but the syntax is clearly different than apache's but still not complicated)
Wow, can't believe I overlooked this. Thanks for the heads up.
For the sake of clarity, you mean that NGINX has better performance specifically with HestiaCP in this context?
This tutorial was helpful, thank you!
Hestia uses nginx by default and doesn't support .htaccess
Wasn't HestiaCP with Apache?
From what I can gather in this thread, it defaults to nginx, which doesn't support .htaccess, but not sure what you mean by "with Apache"
Regardless of hosting control panel nginx has better performances than Apache, but in reality it only matters when you have high traffic website, as nginx could serves more visitors at same time with less resources usage.
If you get used on .htacess and some application you host depend on it you might be better to go with Apache.
Eventually you can go with combo Nginx on port 443, and Apache on port 80 so Nginx will answer to requests on front and pass request to Apache which will communicate with PHP and MySQL in background. This way you will have .htaccess and still have Nginx on front and eventually try some Nginx caching.
Nope, NGINX has better performance overall in probably every scenario possible when compared to Apache (and by quite a margin), if you're able to find any benchmark or niche situation that says otherwise please let me know (Genuinely Curious)
@ServerBachelor
If you had the "Apache" option ticked under "Configure Options" in HestiaCP's installation page on their website before copying the installation command you should be able to find somewhere in settings to enable Apache which will provide .htaccess, You can check their documentation or do a search or use A.I. to determine how to do that because honestly it's been sometime since I used HestiaCP otherwise I'd have helped you better.
This comment has given me a lot to research, but I appreciate it nonetheless. Do you think it would it be more efficient just to take @Envida's advice and convert .htaccess rules into directives?
I believe you, but in that case, why do so many sites continue to opt for Apache and LiteSpeed?
Don't beat yourself up about it; I appreciate the advice.
There could be many reasons, Some come to mind like :
1- They were already built on top of Apache so they wouldn't reconfigure them (or don't have the know-how to do so) to be compatible with NGINX (as NGINX is unable to read .htaccess the websites usually don't function properly until some proper configuration has been done).
2- The websites aren't getting enough traffic to feel the inefficiency of Apache or Performance isn't an issue for them or their servers are handling things okay so they wouldn't both to fix what's not broken.
3- LiteSpeed is a no brainer if your Website/Web App was built on top of Apache in the first place as it's backwards compatible with Apache and can read .htaccess with no issues while also providing similar performance to NGINX (but it is costly especially considering that both Apache and NGINX are free to use).
Glad I could help, If you have any other questions or need further assistance you're free to DM me
I guess Behlendorf wasn't lying when he said Apache could also be read as "a patchy webserver," huh?
And how does LiteSpeed compare to OpenLiteSpeed? Since presumably it has most of the advantages of LS (like .htaccess compatibility) but is also free to use.
OpenLitr> @ServerBachelor said:
OpenLiteSpeed doesn't have .htaccess compatibility but has similar performance to LiteSpeed while being a bit slower it's still something you probably wouldn't ever notice, there should be guides on how to tinker and configure an "a patchy" compatible website to be compatible with OpenLiteSpeed but essentially you'd be doing the same amount of working as getting it compatible with NGINX and getting very similar performance which only leaves you with the downside that OpenLiteSpeed isn't as widely supported by hosting control panels as NGINX is and it's community is small compared to the huge NGINX community.
Although both are constantly evolving, OpenLiteSpeed is way more likely to get .htaccess compatibility support in the future than NGINX.
If you're able to find any guides that get OpenLiteSpeed to work with .htaccess in a simple and easy manner that'd be great because I haven't researched this matter in a while so it might very well be easily done and that'd be great to gain knowledge of.
I'll be keeping myself updated on OLS updates, then! If OLS gets .htaccess compatibility, I could imagine that the currently small community might grow.
Nope, I just misremembered. But if I find a tutorial, I'll remember to share it
I use hestiacp with nginx and apache enabled. apache will run as main webserver which also providing native .htaccess support, while nginx will act as reverse proxy with caching capability.
apache <-> nginx <-> web visitor.
This sounds interesting! Do you notice any effects on speed? And do you have any resources I could look at to create a similar setup?
Its fast.. Simply enable apache during installation.
https://hestiacp.com/install.html
Once installed, setup your domain, upload your web, and go play with .htaccess from filemanager or your preferred ftp client.
If you use WP for CMS, install hestia plugin (just search at plugins page), enable API key from panel, configure your domain to use nginx cache, finally configure hestia plugin with proper API credentials.
This is now good config for https traffic, nginx as reverse proxy. Didn't know that hestiacp supports it out of the box, but that was I suggested also.
Keep in mind that .htaccess files are doing http server configuration on fly so you can add on top of Apache config some rules per directory. So http servers must go through all directory tree structure to cascade all .htaccess files into config on fly that will consume some resources.
Nginx was made on premise if we get rid of all config changes on fly in Apache (like .htaccess) and go with one simple static config file on restart/reload it should be faster, can serve more visitors and will save some resources, so Nginx is simplified Apache.
What to go with, it depends on use case, if it is just shared hosting it is simpler solution to go with Apache and don't deal with configs for all possible applications users would like to host.
If you are going to host less number of sites/application go with Nginx and learn config it per site needs.
And don't forget that even fastest http/s server will not help if bottleneck is php/mysql communication and usually it is.
Thank you for the detailed writeup! I think I'll do a little bit of experimentation with both webservers and try reverse proxying, for the time being.