Hacker News new | past | comments | ask | show | jobs | submit login

My rephrasing of their follow-up actions:

* "Audit our regular expressions and post validation workflow for any similar issues"

* ==> "Not even people who've worked for years on the guts of regex engines can easily predict the runtime of a given regex, but somehow our engineers will be expected to do that".

* "Add controls to our load balancer to disable the healthcheck – as we believe everything but the home page would have been accessible if it wasn’t for the the health check"

* ==> "Our lb check was checking /index, that failed because /index was slow: Lesson learned, let's not lb check anything at all"




I think an audit on regex usage would be fine in this case because it is silly to be using an expensive regex on the server for every home page display. It should be done when the data item is created, not when it is displayed.

Even if they need to support full round trip back to the originally entered data for editing purposes, they could have an extra column in the table for that purpose only, or they could case the displayed output for the post in something like Redis.

I assume, just like those PHP forums of old, they change so much about the page based on the logged in user they can't actually fully cache the home page for all users.

So an audit should just lead them to remove the regex on display anyway, not try to figure out the run time of it.


Regex engines usually have an option to set upper limit on the time they take to match so they don't end up in expensive loops. A simple solution could be to setup such time limits.


I don't think they're disabling health checks in general, just adding a way to temporarily disable checks when they are misbehaving.


Correct. I'll be adding this functionality into Opserver so that we can override the health check in HAProxy when we know better.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: