[1dom]

Can you share a link to your web server please?

I'm finding it hard to make sense of your comment: I can't reconcile some of the stuff you're saying. My gut feeling is you're either ridiculously smart, so smart that defining and implementing a security rules engine for a web server is something genuinely trivial for you, and the world has a lot to learn from you. Or, you're really, really not aware of how much you don't know, so much so that you're going to end up doing something stupid/dangerous without realising.

Either way, an example of a supposedly fast web server written by you should clear it up pretty quickly.

Sorry, because this feels a little rude, and I don't mean it to be, but you're contradicting quite a lot of widely held common sense and best practise in a very blasé way, and I think that makes the burden of proof a little higher than normal.

[solatic]

Not OP, and also not a web server genius, but I read OP's comment as allowing server administers to write policy in OPA then just using https://github.com/microsoft/regorus/ to determine whether to allow or forbid the connection. The web server author can clearly document what is available in input/data to be checked against in the policy. Is it really more complicated than that?

[1dom]

I honestly don't know. I'm in the same place as you: not a web server expert. But I did spend a bunch of time in security a while ago, so maybe it's my own bias to be sceptical of anyone who casually suggests building and implementing their own boundary security solutions.

As well as that, the idea that the language any software is written in is largely irrelevant, especially in the context of performance, is not at all obvious or intuitive to me. I get that it would look that way if you reduce a web server down its core functionality. But that also is a common mistake in educated but inexperienced early career software engineers.

I don't know this stuff, but I know enough to know how well I don't know this stuff. I'm trying to work out if the stuff I'm reading is from someone who I should learn from, or if it's from someone with a lot of confidence but limited experience. It could be either, I'm sincerely on the fence, but a git repo of their web server would help clear it up for me personally.

> Is it really more complicated than that?

I can't say without really doing a thorough review. Even if regorus is 100% reliable rules engine, my understanding is it's a rules engine. I assume there's still a bunch of custom integration needed to manage and source the rules, feed them to the engine, and then implement the result effectively and safely across the web server. It can be done quickly and easily, but to consider everything and be confident it's done correctly and securely? I don't think that can be done trivially by the average human without some compromise.

[sim7c00]

a rules engine for a web server isnt difficult if it doesnt have to carry responsibility for the web app security itself. then its as the posted outlined really...

that being said, its common for new servers to have old vulns, not many coders will go over cve reports of apache and nginx and test their own code against old vulns in those.

i do find a lot of claims about performance or security are oftend unsupported as with this server. it just says it on the readme but provides no additional contex or proof or anything to back up those claims.

my thought is that original commenter gott riggered by that, perhaps rightfully, and points out thia fact more than anything. if you want to claim high performance or security, back it up with proof.

the simple fact its in rust doesnt make it more secure. and using async in rust doesnt imply good performance. it could in both cases. wheres the proof.?

[dorianniemiec]

Regarding the server performance, there are benchmark results on the Ferron's website.