Any suggestions for a simple way in #Django to blackhole all these requests for Wordpress things which will never work?
=> More informations about this toot | More toots from adamghill@indieweb.social
I’m using Coolify with uses Caddy under the hood (I think) so maybe I can exclude some paths in a config or something. 🤔 #Django
=> More informations about this toot | More toots from adamghill@indieweb.social
@adamghill my first thought was a small middleware that checks the request path and blackholes any requests to php files, but going up a level from an application solution to the proxy itself is probably better?
=> More informations about this toot | More toots from josh@joshthomas.dev
@josh Yeah, seems like middleware (with some headers on the response?) and/or robots.txt is the simplest approach. Stopping the requests at the proxy feels like the “right" way to do it, though.
=> More informations about this toot | More toots from adamghill@indieweb.social
@adamghill I’ve done similar middleware for applications running on Fly where I don’t really have access to the proxy level (without shoving my own proxy in there). It works and as long as you do the check early and efficiently (using eg compiled regex matching) I haven’t noticed any major perf issues. I can get away with it because they aren’t super traffic heavy; I imagine at bigger scales you’d want to go straight to the proxy to avoid overloading your app.
=> More informations about this toot | More toots from josh@joshthomas.dev
@josh Well, my side projects aren't lighting the world on fire (yet) so I might just make a middleware and be done with it!
=> More informations about this toot | More toots from adamghill@indieweb.social This content has been proxied by September (3851b).Proxy Information
text/gemini