Aren't you using a CDN? doesn't caching make server-side User Agent sniffing impractical?
I think you don't know enough about the capabilities of nginx to discuss this bit at the moment.
Even with static serving from a reverse proxy cache, it is still possible to perform server-side UA sniffing. In fact, you can do this with zero overhead... the load balancer runs totally in RAM and performing a little work in there has practically no overhead whatsoever... all I can play with are headers, the request and response, but that's precisely what where the UA is.
Because internet forum software is a massive hacker target it can, should be, and is in the case of LFGSS, locked down to prevent code injection.
I don't trust markup software and filters enough to leave it up to the PHP application.
LFGSS uses mod_security to strip out XSS attacks that vbulletin hasn't taken care of.
We even send HTTP 444 when a foul input has been detected (invalid status causes closure of the connection).
I don't leave up to the application what the systems can secure.
Then again, I don't leave up to the system what the application can secure ;)
I think you don't know enough about the capabilities of nginx to discuss this bit at the moment.
Even with static serving from a reverse proxy cache, it is still possible to perform server-side UA sniffing. In fact, you can do this with zero overhead... the load balancer runs totally in RAM and performing a little work in there has practically no overhead whatsoever... all I can play with are headers, the request and response, but that's precisely what where the UA is.
I don't trust markup software and filters enough to leave it up to the PHP application.
LFGSS uses mod_security to strip out XSS attacks that vbulletin hasn't taken care of.
We even send HTTP 444 when a foul input has been detected (invalid status causes closure of the connection).
I don't leave up to the application what the systems can secure.
Then again, I don't leave up to the system what the application can secure ;)