Max :verified: on Nostr: So, random idea about Mastodon and WordPress sites, and the unfortunate circumstance ...
So, random idea about Mastodon and WordPress sites, and the unfortunate circumstance of a link on the former often resulting in an accidental DDoS on the latter. Something that, for example, forced nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqxl5n3v4mwr5xdlfyrr8zg23dwlhnefpe52pdraj7kvaz70lrnyzq6rlnu2 (nprofile…lnu2) to not post links to their articles and nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqeyszugs46q4ngd8tgeysnkwve20n9wewj42lac9cp7s2jrk52u2qyct9ta (nprofile…t9ta) to just block access to Mastodon crawlers entirely.
Of course it's easy to blame Mastodon (partially deserved, there's steps and suggestions to make the hugs less lethal) and/or WordPress (not the fastest CMS on a good day, apart from the community drama), but what about a solution (or at least slightly better workaround)?
What if you write static HTML with just enough in there to render a preview (so the title, some og metadata, and so on, but not much else) and instruct the webserver / reverse proxy to, when the user agent implies Mastodon, serve that instead of handing off the request to a resource hungry CMS?
Even if you get a couple of thousand requests dogpiling in, if it's just static content, you should be able to handle that on anything more powerful than a potato, right?
So that's an addition to your CMS (to write the static files on creation/change) and a few lines in your .htaccess or webserver config, and you're done. The static content shouldn't take that much room, and either way storage is cheaper then having your server hugged to death.
And yes, this shouldn't be the problem that it currently is, this should be solved on the Mastodon end and not by the individual website owners. But here we are.
#mastodon #mastoddos #wordpress
Of course it's easy to blame Mastodon (partially deserved, there's steps and suggestions to make the hugs less lethal) and/or WordPress (not the fastest CMS on a good day, apart from the community drama), but what about a solution (or at least slightly better workaround)?
What if you write static HTML with just enough in there to render a preview (so the title, some og metadata, and so on, but not much else) and instruct the webserver / reverse proxy to, when the user agent implies Mastodon, serve that instead of handing off the request to a resource hungry CMS?
Even if you get a couple of thousand requests dogpiling in, if it's just static content, you should be able to handle that on anything more powerful than a potato, right?
So that's an addition to your CMS (to write the static files on creation/change) and a few lines in your .htaccess or webserver config, and you're done. The static content shouldn't take that much room, and either way storage is cheaper then having your server hugged to death.
And yes, this shouldn't be the problem that it currently is, this should be solved on the Mastodon end and not by the individual website owners. But here we are.
#mastodon #mastoddos #wordpress