I really hoped, that I would not have to do this, but since LiteSpeed support has been ghosting me for a month (since October 10th, 2022), even though I am a paying customer for the LiteSpeed Enterprise server (LSWS), I do not see what else I can do except for calling them out on poor quality of support and advising against use of their services, if you do care for support, when there is a technical issue in the software.
During my migration from Apache to OpenLiteSpeed (OLS) and then to LSWS (due to some limitations of OLS), I’ve setup custom error pages to dynamic pages like https://www.simbiat.dev/httperror/404. I did this, because I had the logic for respective error pages, when something went wrong internally in my index.php file, and I had everything, which is not an existent file in some of the folders to be directed to this script. A pretty common setup, actually (you can see full .htaccess file here https://github.com/Simbiat/simbiat.ru/blob/master/.htaccess). Setup for custom error pages was like 404 => /httperror/404/ (not a line from config, but rather reference to how it was done in the UI). And in the routing logic of my script, there was a check for $_SERVER['REDIRECT_URL'] values, to see if this was an internal redirect to the error page.
And it worked pretty well in OLS (and Apache): accessing a file like https://www.simbiat.dev/.well-known/security4.txt would trigger the same 404 page, but showing the original URL in it (for traceability), while accessing https://www.simbiat.dev/.htaccess would show appropriately styled 403 error. Not so much in LSWS, which showed LiteSpeed’s internal 404 or 403 errors.
I created a ticket #945335, in order to get to the bottom of it. My hunch was that when LSWS encounters respective error internally, it was not applying rewrite rules. During some initial communication with support and digging through logs, I saw errors like “File not found [/path/to/folder/htdocs/httperror/404/]”. Which was understandable: there was no file like that, indeed, it was expected, that it will redirect such request to index.php.
From here… I do not know what started happening exactly, but last messages from support were suggesting me to direct custom error pages to /index.php/httperror/404/ or index.php?httperror=404. Which did not make sense, and would not solve the problem in any way, because… I would not even be able to create such files. It’s not how PHP processing or filesystems work. I was open, that I saw this as laziness and ignoring of the real issue.
But I went ahead and wasted some of my time to confirm my assumption about what’s going on in the server’s code. Long story short, if I create a file like /httperror/404/404.html and link it to 404 error – the requests do get internally redirected to index.php, which I know on the script level based on value from $_SERVER['REDIRECT_URL']. You can see that for yourself on https://www.simbiat.dev/.well-known/security4.txt or https://www.simbiat.dev/.htaccess.
I explained this in way more details on October 10th, along with assumption, that the issue can probably be solved by changing order for a few calls, so that first you do rewrite rules, and then check for a file. And since then… Complete silence. A week ago, I even opened a new ticket, where I asked for an update for this one – it was merged to the original, and still no human-readable reply.
Today, though, I learnt, that there are situations, when you can get shown that very “dummy” file. If you copy-paste (and seems like only copy-paste) https://simbiat.dev to address bar and press enter, instead of getting redirected to https://www.simbiat.dev (as per rewrite rule), you will get redirected to… https://simbiat.dev/httperror/301/301.html. A page for a custom error for 301 HTTP code, which is a code for redirect. When I set this up initially, I did not think you could ever get there (which is clear from text on https://www.simbiat.dev/httperror/301/), but just wanted to cover all my bases. Apparently… It can. If you have troubles reproducing it, you can see it on this video https://youtu.be/ulNt-LGdG8A along with 404 and 403 errors with respective notices, I’ve added, until LiteSpeed decides to fix this.
Why am I telling you all this? Well, to let you know what kind of support you can get with LiteSpeed and to caution you before you decide to buy their software. I know not a lot of people will see this, let alone read the whole story, and even less people are using LiteSpeed or considering using it. I want this knowledge to be out there.
I am ok if solving this problem will take time. I can understand that. But literal ghosting, without even bothering to let me know if the team acknowledges, that this is an issue which needs to be addressed properly (and not through some dummy files) is unacceptable. I can’t, in good conscious, recommend such a company to be used in any business endeavor.
