Ticket #945335 - Custom error pages do not work [MERGED]

Lisa,

I am fine if this is "design", but:
1. The "solutions" that were provided did not work, and I believe I've shared enough information to explain why. And, to be honest, since the same not working solution was advised twice, that does not sing praises about competence of support personnel. At the least you could acknowledge that and say something like "Indeed, this does not work, we will update our internal documentation" or something along those lines.
2. As I've showed on screenshot on the forum (attaching it, too for your convenience), this "design" contradicts the help text shown in the UI.
3. If by developer involvement you mean message from Gary Duan, then I would not call that involvement, since this was just an assumption, that there is an error in .htaccess (which is totally fine, at least at that point in conversation)
4. If by developer involvement you mean message from George Wang - that's not really a professional response to begin with. "Why use dynamic error pages?" simply implies no understanding of why people use dynamic pages. Which I also covered on the forum
5. Twice in this very ticket I asked to provide technical justification, of why Litespeed believes, that this is how this feature **should ** work. Attaching 2 screenshots for your convenience, but you can find the text in the ticket. And no "redirect protection" is not a justification, because I've proven with evidence, that there is no redirects done, when referencing dynamic pages.
6. Even in this very ticket, I said what answer (even copy-pasted, and even if I won't really believe it at this point) would satisfy me. Attaching a screenshot for your convenience. Not sure why it is hard to copy-paste it. That forum thread also had it. And I am pretty sure someone from the staff read it, since you finally decided to close this ticket.

Again, my problem is not that this is "by design". My problem is with Litespeed stance on the matter, that to me reads as "we don't give a rats ass about your use case". I have no idea what internal structure your company has, what internal processes, but as an experienced tech support specialist, I strongly believe, that when you get a case in support, where "inconvenience" for the user is caused by "design" you work with the user to find potential ways to improve the product . It can start with a workaround (which we kind of got, although, technically, it was me, who found a working one), and then continue as registering a feedback item in your project management system.

For you convenience, I will once again go out of my way and even provide you the text for potential messages, that will satisfy me as a customer. Feel free to copy-paste them in your next reply, when you will be closing the ticket again. Or you can even combine portions of them, if you want.
1. We understand that this is not ideal for you, but this is how LSWS is designed, and it's done so because %enter_technical_justification_here%. As per our developers/project managers, this is not going to change. We will update our documentation with the workaround you found, so that other users can use it, as well. We will also update the product's help tips and remove reference to dynamic pages/scripts for custom error pages.
2. We understand that the help tip in the product have caused confusion. We will update it to remove any reference to dynamic pages or scripts in error pages, since this is not something that LSWS is going to support.
3. We understand that lack of this feature is inconvenient, and the use case does seem valid. As such we will add a backlog item to look into possibility of supporting dynamic pages for custom error pages. Unfortunately, we will not be able to keep you in the loop in regards to progress on this item if any.

I do not believe I am asking a lot, when I am asking to copy-paste one of these answers. It will literally take a couple of seconds at most. I do not find any of them unreasonable, but if you do find any of this unreasonable, please, do let me know.

Almost 5 months have passed since last reply from a support person. Is this the norm in Litespeed?

I wonder what note does this ticket have in your ticketing system, so that people do not bother with it. I mean, I would assume it has breached several SLAs now due to its age.

And the funny thing is... I only need formal confirmation, that "yes, there is a weird behavior, we will look into it, when resources are available". I mean it will literally take less than a minute to provide such a simple reply, which does not even mean that you will be actually fixing this (ever).

But I guess, I am asking too much. How dare I expect quality support, right?

Still silence? My birthday is on May 12th, any chance to get a response by that time as a present?

Happy New Year! Wish you to have an ability not to ghost your customers!

Merry Christmas! I am still hoping for a reply, as if Santa was real. But, guess you would not care enough to give such a cheap present even on Christmas. Maybe for New Year's? Or my birthday, which is on May 12th.
Or maybe you can, at least, have enough decency to tell me the ETA, when I can expect your answer? Or just send a brief "Fuck you, loser", which would make your feelings about your customers crystal clear? Even that would be much better than this silent game.

Still ghosting me? Even after tagging LiteSpeed on Facebook and LinkedIn (also LTT forums , but there is no tagging there)? Guess, last time the reply after tagging was just a pure coincidence, after all.
Funny thing, that if you did spend just a little bit of time you are spending on ghosting to, at least, read my complaints, where I even reiterate what I expect from support (and no, that's not an immediate fix for a perceived issue), maybe you would have learnt a bit about how to provide quality support.
But looks like you really, do not give a damn about your customers' experience. Wonder if anything would change, if I was a corporate client.

Continuing to ghost me?

Since you are ghosting me again, I've created a video and uploaded it to YouTube: https://www.youtube.com/watch?v=zlUtD00NnD4 (and all the logs are attached to this message)
I show in the video, what happens according to logs, when we have internal error page, when we have /index.php/httperror/404 (1st suggestion from support), /index.php?httperror=404 (latest suggestion from support, which seems to be internally truncated to index.php), my original (and intended) setup of /httperror/404/ and my current setup of /httperror/404/404.html.
As per logs, in case of your suggestions, the final Source URI ends up as /index.php/httperror/404 and index.php respectively, which are not recognized by the script on the website (the message displayed is Unsupported route).
With /httperror/404/ the failure comes from the fact, that LSWS is looking for /httperror/404/index.php, fails to find it and thus we get internal error page (interestingly, if we remove the last slash to get /httperror/404 - we will get 301 redirect to /httperror/404/ page).
And with /httperror/404/404.html we end up with redirect, that has a Source URI, that (essentially) matches the regex of ^httperror/\d{3}/.* and thus the script finally processes the page as intended.
The video also shows the strange behavior when you have a custom error for 301, but I am not sure if I see a proper use case when you would need a custom error page for 301 or 307, so maybe this is not an issue, but it surely has a different logic compared to other errors.

I believe, the issue is with the order of actions when there is a value for custom error page. From what I observed, it goes like this:
1. Remove GET (?httperror=404 in the tests) parameters from path
2. Check if path is a folder (possibly does this based on trailing slash, and not using something like is_dir() (from PHP) or something like [ -d "path" ]
1. Check if there is an index file based on setup for virtual host
1. If it's not there - fail and show internal error
2. If it is - use path to it as new "Source URI"
2. If it's a file, use its path as new "Source URI"
3. Apply rewrite rules as per setup

I can see situations, where this sequence of actions could, theoretically, provide some benefits in performance, maybe catch errors in case of non-existent files/folders, but... As we can see - there are cases, where it fails, because the step 3 in main sequence should be step 2 (or maybe even step 1).
If it is, then in case of setup like mine, you will get to index.php even a bit sooner, since you will drop checks for whether it's a file or folder in the first place.
I understand, that changing this logic for everyone may not be ideal, thus, what can be done with relative ease is implementing a checkbox on each custom error page (that is in their respective window setups), something like "Early rewrite", which would trigger rewrite rules for custom errors on 1st step, instead of 3rd.
Or, as I've mentioned before - see, how it's done in OLS.

Please, note, that my patience in regard to quality of support being received here is running thin. This video and alaysis of the logs are definitely not something I should have been doing in the first place, because I should not be receiving nonsensical advice in the first place, let alone spend my time not rebuke it several times.
If you need more time to analyze the data I've provided you - that's fine by me. Let me know some kind of ETA, and I will get back to you at that date, unless you return sooner. If you will ghost me... Or continue to suggest nonsense...
Well, I've already setup my site to have a message to suggest not using LiteSpeed because of this issue. I will be advocating against the software going forward and will not be using it after my license expires (although I do not want to do that). And I will try to get in touch with whatever tech-news websites/channels to share this story with them, too. Maybe it won't account to much, but I will try.

And not because you are not fixing this issue "ASAP". No. My problem is with very low quality of support, ghosting and inability to speak with me as developer with developer. I mean, provide me a sensible justification, why the same basic feature works differently in LSWS than in OLS and Apache, provide me explanation of the benefits, that I can appreciate as a developer and tech supporter - no complains will come from me.
So far, I have not received that, and instead wasted quite a bit of my time.

Oh, and just in case, this could be of any help: I am even ready to have a videocall (Zoom, Meet, Teams, whatever), where I can show live to the expert, how this works and that it's not how it's supposed to be working.

Lisa, if you check the ticket, you will see, that I already rebuked this. Your solution does not work, because Custom Error pages in LSWS do NOT apply rewrite rules! And index.php?httperror=404 is NOT a file! It's a GET request. Current logic for Custom Error pages will FAIL to find it, because it *EXPECTS** a file!
I've been ghosted for a month to receive the same bullshit answer? Really? Are you frigging serious? Was there even 1 developer who even glanced at the ticket and all the investigation, that I've shared?
And are you seriously selling me the idea, that it is OK to get an error page for a 301 redirect, instead of an actual redirect?
I've already shared posts in social media telling how bad the support has been with this issue. I am saving the HTML of this very ticket (in case you decide to ban me or something) and I will be ready to share it as well. I may not be read by many people, but at least there will be information with evidence, of how incompetent the support is.
I demand an expert (that is a developer, because support is clearly not aware of how things really work in a logical world), to look at the investigation details, that I shared and to, at least, try to provide me believable technical justification for such behavior. Which, I once again remind you, works absolutely differently (and normally) in OLS. And it's not something where "these are different products" will work, because this is a very basic functionality.

I found another "result" of this issue: you can get to see a redirect error page. If you copy-paste "https://simbiat.dev/" (specifically copy-paste apparently), instead of getting redirected to https://www.simbiat.dev/, as per .htaccess, you get redirected to https://simbiat.dev/httperror/301/301.html. Specifically, the actual contents of that file. Once you refresh it, though (sometimes Ctrl+F5 is required) you will get a proper error page, fully styled as the main website.
If you have troubles reproducing it, you can see it on Youtube https://www.youtube.com/watch?v=ulNt-LGdG8A

Seriously? You found the time to merge 2 tickets, but you can't find the time to write some kind of response, instead choosing to ghost a customer?

Hey! I would like to get an update on ticket 945335. I provided proof of an issue with logic applied to custom error pages, but I am being ignored there for quite a while now. What's the status of investigation? Do you confirm that there is, indeed, an issue and you are working on it?

IP Address: 87.92.61.151

Anyone alive there?..

Hello?

Any news?

Get developers on this. I am sure that fix would be to just change order of a couple of function calls.
Or if you think that this is result of the alleged "redirect protection", let's disable it to test that out. And provide some description, that could convince me, that this is normal.

But, most likely, you can't because there is none. I've been in tech support for 13 years and been coding for over 5 years, I have a sense for logical errors. Here's another attempt to prove a point to you (not like you care, from the looks of it, which does put the support quality quite low in my list):
I've set 404 error to "/httperror/404/" and 403 error to "/httperror/403/403.html" file. Unsurprisingly, the latter on the example of https://www.simbiat.ru/.htaccess redirects to index PHP, and since "/httperror/403/403.html" matches the regex for an error page - proper custom 403 page is shown. While for https://www.simbiat.ru/.well-known/security4.txt - still same picture (which does change, if I set redirect to "/httperror/404/404.html".
Now what I not just want but need you to do, is utilize the SSH access I've given you and compare the logs for https://www.simbiat.ru/.htaccess and https://www.simbiat.ru/.well-known/security4.txt (of course after following the links to get the fresh data)
If you do that you will see, that https://www.simbiat.ru/.well-known/security4.txt does not redirect to index.php, because "/httperror/404/" is not a file (for which there is a clear error in the logs) and rewrite rules are not applied, but https://www.simbiat.ru/.htaccess applies rewrite rules, because "/httperror/403/403.html" is an existing file.
As a developer I see a problem here, because this indicates logic like this:
1. Check if URI provided in link for custom error is a file
2. If it is a file - apply rewrite rules and open it based on the rewrite rules
3. If it is not a file - show internal error page
The problem here is, that rewrite rules should be applied regardless of whether link is an existing file or not, and check if it's a file should be applied only if rewrite rules result in a path to a file, which does not exist.
And as I said, this is solved by slightly changing the order of actions:
1. Apply rewrite rules
2. If resulting link is an existing file - open it
3. If resulting link is not a file - show internal error page
Easy. Will literally take a minute to fix.

Oh, and another thing, that may indicate a problem with current logic is lots of errors like this:

2022-10-07 04:55:17.950288  INFO    [1314330] [T0] [216.244.66.238:46650#htdocs] File not found [/usr/local/webserver/htdocs/httperror/301/]

Which surely is not normal. Although, to be honest, I am not sure I see a situation where a page for 301 would have been shown at all.

No. Why are you doing this? Laziness? Why should I point error page to index.php with additional GET parameters in URL, when everything is supposed to be sent to index.php through .htaccess already? This does not make sense. Besides, your suggestion still relies on a physical file, which in case of "index.php?httperror=404" does not exist. You are NOT solving the problem, you just ignoring the fact, that internal redirects do not work with folders. Which IS a problem and NEEDS to be fixed.

Important thing I've forgot to mention: to track internal redirects, routing logic also checks $_SERVER['REDIRECT_URL'] and if it has "httperror" route in it, which kind of "overrides" anything else. So, if there was an internal redirect to /httperror/404/ router would never show page for 400.

I have shared .htaccess and have access to it through SSH as well... Strange to see such a question.
No, there is no rule there specific for /httperror/*/. All requests except a few exceptions written in .htaccess direct to index.php, which in turn calls a router function, which calls various functions based on URI_REQUEST value, essentially generating a list of values, that are passed to Twig, which generates appropriate HTML.
And no, as I explained before as well, you saw a 404 error for 404.html (not 404.shtml), because "404.html" is not a known route in router's logic and it shows 404 in such cases. And as I also mention I specifically set it to show 400 for now, so that you would see a difference. Right now, I even placed a 404.html file on server and... What do you know, https://www.simbiat.ru/404.html is returning 400 (check headers, not the visual representation).
Furthermore, using "index.php/httperror/404" does not make sense, because index.php is a file, not a folder, and for PHP it would make more sense to have "index.php?httperror=404" to add GET values, but that does not fit the routing logic at all, and even if it did - "index.php?httperror=404" is still not a file.
But knowing, that, I've set 404 error page to "index.php?httperror=404" and it looks like it does properly redirect to index.php now (wonder why? maybe because I am referencing an existing file?..), but, same as with 404.html - I get code 400, as explained before. Which implies, that the issue is with LSWS looking for folders. I've created folders httperror/404 and httperror/403 - but it still does not help.

And once again, I am reminding you, that the same setup works in OLS and Apache. And no matter how you want to continue to deflect this issue, it IS an issue and needs to be addressed to developers for a fix.
I also really hope that I will not need to repeat anything from what I've already explained ever again. This is not a live chat, you should not feel pressured for time and should have a couple of minutes to read through the whole ticket, if you do not remember all the details.

Rewrite to "static/.well-known/security4.txt" is within expectations, because .htaccess has

#Rewrite well-known
RewriteCond %{REQUEST_URI} "(^|/)\.well-known/.*" [NC]
RewriteRule "(^|/)\.well-known/(.*)$" static/.well-known/$2 [QSA,L]

And even

#Rewrite for static content
RewriteCond %{REQUEST_URI}::$1 ^(.*?/)(.*)::\2
RewriteCond %{DOCUMENT_ROOT}%1static/%2 -f
RewriteRule ^(.*)$  static/$1 [END]

Since I wanted a folder for static content as well as different common stuff like robots.txt and PKI verification, so that it would not clutter the main directory.

And regarding the redirect to /httperror/404/ - it looks like you did not read carefully, because, even though, there is

redirect to: URI=[/httperror/404/], QueryString=[]

which indeed, confirms the internal redirect, and

Error Page, processContextPath() return 26

which does not necessarily mean "ok", because I would assume that "return 26" means "return code 26", that is there was an error, since "ok" usually means return code 0. Regardless, there is also

File not found [/usr/local/webserver/htdocs/httperror/404/]

which once again confirms, that LSWS expects it to be a file and nothing else but a file, which is a problem, for which I've raised this very ticket. Why does it not apply rewrite rules after redirecting to /httperror/404/ and failing to find a file? Or maybe it should do it before, doing that, that's also a possibility. But it should apply the rules from .htaccess, because it looks like it did correctly match the context to "/":

2022-10-04 19:33:29.328756 [DEBUG] [450201] [T0] [108.50.218.194:59123-H3:915C2E81778D422C-0#htdocs] Matched HTA cache of [/] by URL [/httperror/404/] to context [/]
2022-10-04 19:33:29.328767 [DEBUG] [450201] [T0] [108.50.218.194:59123-H3:915C2E81778D422C-0#htdocs] Find .htaccess context with URI: [/], location: [/usr/local/webserver/htdocs/]

And even if this is "normal": what do I need to do to make LSWS run a script, instead of blindly trying to open a file? Once again: this setup works perfectly well in Apache and OLS.

Ok. Details below. Please, do not do any potentially breaking changes (including upgrades) without letting me know. As I've mentioned the last time after support intervention, I lost my database (due to failed updated apparently) and started sending lots of spam. Again, not saying, that it was necessarily caused by whoever connected, but the timing of the issues was too on point. So just let me know if you will need to anything "serious" besides looking at settings and maybe restarting services.

User: lssupport
Password:

gfe.nwb*YRT7ude*dpu

Firstly, I already mentioned twice, that https://www.simbiat.ru/.htaccess does not show custom 403 either.
Secondly, if you want more pages - https://www.simbiat.ru/css/modules/asdasda.css or https://www.simbiat.ru/js/Common/asdasd.ts This happens for any directory, for which I allow loading of any file from. It happens to https://www.simbiat.ru/img/asdasd.svg too, if I remove rewrite for non-existent images.
Thirdly, it's not about the rewrite rule, because if it was, this would not work in OLS, but it does work in OLS.
Fourthly, it does work in Apache. Attached are the config files from Apache and .htaccess (same one is used in LSWS, of course)

Enabled rewrite debug and gathered logs again. Attached are access and error log respectively with "ip_only.log" having only the lines with my IP (2001:14ba:a0f5:ca00:8dbe:7c92:6e9b:6ee) at the moment of the test: first from access log and then (after some new lines) from error log.
I tried accessing https://www.simbiat.ru/.well-known/security4.txt (expecting custom 404 page), https://www.simbiat.ru/.htaccess (expecting custom 403 page), and https://www.simbiat.ru/asdfads (one of the pages, that your referenced, but after I've updated the error code sent by script to 400 for the sake of the test (and I am keeping it up for now, too)).

No. I explained it earlier, that "https://www.simbiat.ru/asdfads" does get redirected to index.php, where the script fails it, because it's an unsupported route. I previously used code 400 there, if you want, I can temporarily revert it to that so that it would be clearer.
For https://www.simbiat.ru/.well-known I have a rule for overwrite, so that requests to that folder (and any files/subfolders in it) would go to that folder, not to index.php

Indeed, I totally forgot about enabling logging for rewrites, I can do that tomorrow morning (my morning, I mean) and share logs.

I've also noticed these kind of errors:

2022-09-29 04:57:28.838675 [INFO] [229008] [T0] [185.191.171.15:63418#htdocs] File not found [/usr/local/webserver/htdocs/httperror/301/] 
2022-09-29 04:57:31.908773 [INFO] [229008] [T0] [77.88.9.139:57690#htdocs] File not found [/usr/local/webserver/htdocs/httperror/301/] 
2022-09-29 04:57:32.125004 [INFO] [229008] [T0] [77.88.9.137:35392#htdocs] File not found [/usr/local/webserver/htdocs/httperror/301/] 
2022-09-29 04:57:34.224058 [INFO] [229008] [T0] [185.191.171.19:11954#htdocs] File not found [/usr/local/webserver/htdocs/httperror/301/] 
2022-09-29 04:57:36.416511 [INFO] [229008] [T0] [77.88.9.139:61886#htdocs] File not found [/usr/local/webserver/htdocs/httperror/301/] 
2022-09-29 04:57:36.496761 [INFO] [229008] [T0] [77.88.9.139:57690-2#htdocs] File not found [/usr/local/webserver/htdocs/httperror/301/] 
2022-09-29 04:57:47.860980 [INFO] [229008] [T0] [54.36.148.199:46931:HTTP2-1#htdocs] File not found [/usr/local/webserver/htdocs/httperror/301/] 
2022-09-29 04:57:48.793272 [INFO] [229008] [T0] [207.46.13.88:65024:HTTP2-1#htdocs] File not found [/usr/local/webserver/htdocs/httperror/301/] 
2022-09-29 04:57:54.413882 [INFO] [229008] [T0] [77.88.9.139:43360#htdocs] File not found [/usr/local/webserver/htdocs/httperror/301/] 

Which proves, that this behavior is true for other types of errors. And also makes me curious, how would one get a situation, when instead of an actual redirect you get a 301 error page

I think the article about debug log may need an update, because for me error log is stored as /usr/local/lsws/logs/error.log, not as "error_log" and I did not change the settings for it.
As for the logs themselves... They do not seem to have that much:

2022-09-29 04:57:03.377768 [INFO] [229008] [T0] [2001:14ba:a0f5:ca00:800f:4492:34ba:bc9b:55715-H3:8599C898DCC6092E-0#htdocs] File not found [/usr/local/webserver/htdocs/static/.well-known/security4.txt] 
2022-09-29 04:57:03.377921 [INFO] [229008] [T0] [2001:14ba:a0f5:ca00:800f:4492:34ba:bc9b:55715-H3:8599C898DCC6092E-0#htdocs] File not found [/usr/local/webserver/htdocs/httperror/404/] 

But this does prove, that LSWS is checking if "/httperror/404/" is a file, fails on that thus does not do anything else. My bet is that either needs to first apply all respective rewrite conditions and then check do redirect or it should do that if there is no such file.

That does not make sense, especially since:
a) .htaccess is already on virtual host level
b) there is no reason for LSWS to always assume a physical file in custom error pages, because I can be pointing it to a CGI script, which I kind of doing here, really
c) it does understand if the custom page is just "/" which is, technically, a dynamic page
d) this setup works perfectly well in OLS
e) this setup works in Apache (through .htaccess even)
And, please, do not tell me "OLS is different product". I know it is, and I had to move from it to LSWS because it was not supporting the basic things, that it was supposed to support (like .htaccess supported only rewrite rules, and Header directive does not support conditions). But LSWS developers should be able to check what is the difference in respective portion of code between LSWS and OLS, that somehow makes OLS apply rewrite rules to Custom Error pages, which LSWS does not. Or at least, that is my assumption based on observation of behavior in both systems.

To be honest, the quality of support I am getting for quite basic things, is making me think I've wasted my money... Because in 2 tickets, which are essentially bug reports, I see attempts to convince me, that there is no issue and it's me who is stupid.
As I've mentioned in one of the tickets, I've been in tech support for 13 years now, and I totally get it, that the only 2 support guys are probably overloaded enough to be simply tired, but that does not mean you should not be as professional as possible, even if I have to wait longer (which I can tolerate).
If you think that your expertise is not enough at this point, and you do need to get devs on this - get them. Reassign the ticket to appropriate department. Or even ask me to reraise them as bug reports.
I am not expecting "premium" support with resolution within hours, but I do expect at least some level of competency and understanding of customers' use-cases and their expectations. Telling me to use a static file in my absolutely normal use-case is almost equivalent to saying "FU"...

Sorry, but no SSH for you, guys. It's a huge "coincidence" that exactly on the night that someone logged in with "lssupport" account I created for the tickets, thousands of spam mails started being sent. Not saying that whoever connected did something (at the least, I do not have any evidence), but at the moment my trust is... Shaky, at best. At least until I and my VPS provider find some vulnerability that might have happened.
Tell me exactly what you need - I will provide. If you need logs, I should be able to just download them and attach here. Should I just dump all the /usr/local/lsws/logs files? Is there something I can do to somehow limit them? Like stop the server, purge the logs, start it, try accessing the non-existent file, that should generate a custom error page, stop the server, download logs?

No. The custom page that you see with a physical file is shown because "/404.html" is not a supported route within index.php script, for which the script issues 404 error.
Also, once again: static file does not suit me. Static file implies, that I need to maintain the website style not only in Twig templates but also in all static files. I am not willing to do that, especially when, at least CSS and JS paths are dynamic (cache busting). Static file does not work for me at all.
Please, ask the devs to check how it works in OLS and apply the same logic in LSWS.

I'm sorry, but as a tech supporter for 13 years, I have to highlight, that

but why to use dynamic pages?
in this context is a very unprofessional answer.
Dynamic pages are used precisely because they server dynamic content. One can have dynamic blocks on the pages (like a user panel, or live chat or something else), which may be populated server side instead of hydration (and then optionally get rehydrated, if required). If one want to have consistent experience for the user across all pages, including error pages - one would need to generate error pages' content dynamically as well.
Answering like this implies you do not understand or do not know various use-cases and approaches with dynamic content generation. I sincerely hope that you will read up on those.

As for "redirect" or rather rewrite rule, you could have also checked .htaccess, since you have access to SSH. You will see that it's setup in a way that almost all requests will be rewritten to index.php. This is also quite a common occurrence, which not only allows for somewhat tighter security, but can also allow for generation of dynamic error pages based on various conditions, including original request.

So, no, using a static 404.html file (or whatever other file) does not fit. On the example of 404, I am attempting to generate a suggestion of a link, that user meant. I could use JS for this, but why should I, if I am doing some stuff on backend regardless of whether there is an error: at least generating/updating user session, checking if user is authenticated and generating a sidebar based on that.
I know you may suggest using redirect in the setup by using full absolute URL, but then I would need to implement logic, that would somehow transfer the initial page form which redirect happened, in order to suggest a potentially correct link. Which is doable, until you consider that somehow there were several redirects, which will complicate things even more. No need to do that, when web-server is fully capable of doing internal redirects (or rather rewrites).

This feature works perfectly well in OLS, so from my perspective, devs just need to replicate the logic from OLS in LSWS. My guess is that currently, the URL field is treated as a file, unless it's a full absolute URL, and if it does not exist - show internal error page, if does - it tries to open the file after applying rewrite rules. If that's the case, moving the application of rewrite rules up in the algorithm should "fix" this. And if it does - it's a very easy fix.

Documentation does not prohibit dynamic pages and using dynamic pages worked in OLS.

As for password: I got a notification about failed login to web-panel, so I would assume you mixed the credential pairs somehow. I confirmed that both work. Be sure to drop the double quotes!

No, that's not the case:
1. It excludes any paths that start with .well-known, so https://www.simbiat.ru/.well-known/security4.txt fails on the 1st rule already
2. I did test without - same thing
3. You can also check https://www.simbiat.ru/.htaccess - it's prohibited both by .htaccess and, I believe, Litespeed as well, so it should show the custom page for 403, but it does not

Admin panel is https://88.85.67.178:7080/, username "Simbiat", password "wPff3aXhqJLEZBUYi2Ha" (without quotes obviously)
ssh: user "lssupport", password "hjt!YFR.cec8pae4yat"

Hi!

For my website https://www.simbiat.ru I've setup custom error pages in LSWS, as seen on attached screenshot, but for some reason when I go to some non-existent URL like, for example, https://www.simbiat.ru/.well-known/security4.txt (https://www.simbiat.ru/.well-known/security.txt exists and does work), I get the standard LSWS error page. The same setup worked in OLS.
Important thing is that these pages are not actual files or folders, they all are rewritten to index.php, but they do "exist": https://www.simbiat.ru/httperror/404/
Interestingly, though, when I tried to setup 404 page to /404.html (which I put on server with the only 1 <p> tag in it, just for test) - it did load the expected page somehow. I mean it loaded what I would see from /httperror/404/, not the 404.html.

I think that the only relevant difference is that due to OLS limitations I was trying to make the setup through contexts (although there was not "httperror" context), while since supports more stuff in .htaccess, I am using that one (also attached, of course). I tried adding "/.well-known/" context, but it did not do anything.

Could you, please, advise, what may be an issue here?

IP Address: 78.27.97.25