Guarding a Seaside Application against an F5 refresh attack

I've had a request to help understand how to guard a large page, being served up by Seaside, against an F5 refresh attack where the user can just hold down the F5 key and send refresh page requests as fast as the F5 rate-limit is willing to go.  I know some web-browsers artificially rate-limit F5 because this is such a popular DOS attack.

Originally, there were some concurrency issues found in Sst when faced with such an enormous number of requests so fast...but I got those fixed up and neither I, or the requester, can duplicate the original concurrency issues anymore.

While that's nice, there still is the question of how to handle this situation.  I'm not a web guru, or a seaside guru...so I was hoping somebody had information on how to protect against this?  
Would I be correct in assuming that there is something at the application/system level that needs to be done?

I can certainly see various tweaks in Sst to help fulfill requests faster...but not at the level we are talking about since these pages are so large.

Any help would be appreciated...thanks!

-- Seth

I'm no expert on web technologies, either. However, I think the usual practice is to handle it at the e.g. Apache front-end. If you get repeated requests for the same URL, you can give the response from the first one served to all those that queued up while it was being processed.

Rate limiting, deduplication, and load balancing all fall in this area.

That ignores idempotency or lack thereof issues, of course. It would treat multiple identical requests as idempotent requests for data and suppress any side-effect the request might have implied (e.g. incrementing a counter).

This is good information I will be passing along.

-- Seth

On Wednesday, February 24, 2016 at 12:25:30 PM UTC-5, Richard Sargent wrote:

On Wednesday, February 24, 2016 at 8:13:22 AM UTC-8, Seth Berman wrote:

Hi All,

I've had a request to help understand how to guard a large page, being served up by Seaside, against an F5 refresh attack where the user can just hold down the F5 key and send refresh page requests as fast as the F5 rate-limit is willing to go.  I know some web-browsers artificially rate-limit F5 because this is such a popular DOS attack.

Originally, there were some concurrency issues found in Sst when faced with such an enormous number of requests so fast...but I got those fixed up and neither I, or the requester, can duplicate the original concurrency issues anymore.

While that's nice, there still is the question of how to handle this situation.  I'm not a web guru, or a seaside guru...so I was hoping somebody had information on how to protect against this?  
Would I be correct in assuming that there is something at the application/system level that needs to be done?

I'm no expert on web technologies, either. However, I think the usual practice is to handle it at the e.g. Apache front-end. If you get repeated requests for the same URL, you can give the response from the first one served to all those that queued up while it was being processed.

Rate limiting, deduplication, and load balancing all fall in this area.

That ignores idempotency or lack thereof issues, of course. It would treat multiple identical requests as idempotent requests for data and suppress any side-effect the request might have implied (e.g. incrementing a counter).

I can certainly see various tweaks in Sst to help fulfill requests faster...but not at the level we are talking about since these pages are so large.

Any help would be appreciated...thanks!

-- Seth