Introducing a Fair Use policy

[aaronpowell]

When @tathamoddie and I created httpstat.us back in 2011 it was mostly to scratch an itch we had, and we had no major plans for it beyond writing the code.

Fast forward a decade, the service is still up and doing more traffic that we'd ever anticipated. While we never really promoted it or did any pushes on it, it has picked up a lot of users and been used for a wide variety of scenarios.

But with success, comes issues. We have some very clear performance issues, which are discussed in #89 and for httpstat.us to continue to provide the service people want, it's time to properly look at addressing them.

Introducing a fair use policy

Up until now the service just is, you hit an endpoint and you'll the right response. We've never done anything to describe how you should use the service, we've just believed that people will be fair to everyone. But as I've been diving more into the logs around how the service is used; it's become clear that we need to have some documented guidelines on what constitutes fair use.

The first time we tackled this was with dbbda4a, which killed a particular endpoint that was being abused, or at least, being used in a way that we considered abuse.

Unfortunately, it appears that we've hit the limit on how effective that hack is and it's time to do a more permanent solution.

Addressing performance issues

There are a few things that we'll be tackling over the next little while in an attempt to address the performance issues we're experiencing and instigating the fair use policy.

First, we'll revisit PR #91 and get the codebase upgraded to .NET 5. It's about time to move on from the .NET Framework, it's served us well for a decade, but it's showing its age and .NET 5 opens up the door to a lot of performance improvements. It'll also make it easier for people who wish to self-host by having containerisation as a viable option, something that .NET Framework can't offer us.

Secondly, introducing an API token combined with rate limiting.

Access tokens and rate limiting

Complete unbridled access has served us well for the past decade but going forward we need something smarter, and this will be in the form of rate limiting.

With no token provided, users will be limited in the number of requests per minute they can make to the service. We don't have the figured on what it'll be yet, but the intent is to have it without the bounds of what we believe to be fair use.

If you need to make more requests than that, you'll be expected to register and provide an access token as part of the request. We don't have the final implementation sorted out, but it'll be a case of providing a token via either a header or parameter on the request. Again, this will be subject to a level of fair use but is more for accountability as we presently have no way to monitor for potential abuse and as I've stated, the whole point of this is to ensure it's fair for everyone.

Conclusion

The fundamental goal of httpstat.us hasn't changed, we want to make an easy-to-use site for testing how different status codes can be handled in your applications, but we're at a point where it's time to instigate some restrictions to avoid abuse and keep the service available for everyone.

There isn't a timeline for this happening, but we'll make sure that things are communicated as well as they can be, given we've got no way to contact users! 😅

If you have any questions, comments, or concerns, sound off in the comments below.

[RobFaie]

It would be nice to have flexibility in the way tokens are provided. Most of my test suites would be easily updated to include a query param based token but one or two would be more easily updated to use a header of some sort.

[aaronpowell]

@RobFaie I've been looking at using Azure API Management, rather than a custom solution.

APIM makes it easier for me to setup rules for rate limiting and token validation, plus it means that for self-hosted scenarios you won't need to do anything, as you won't have APIM in front of it.

[RobFaie]

Good plan. It supports both header and query param by default ;)

Is APIM going to add much to the cost overhead? Perhaps it's time to turn that sponsor button on.

[aaronpowell]

I've got to look at the pricing plans, but yes, it's probably going to cost more than the AppService does 😫

[neilboyd]

You'll want .Net 6 now since it's LTS. .Net 5 support ends next month.

Perhaps you should also consider the sleep parameter since you're paying for that time on a consumption plan.

[aaronpowell]

It is a .NET 6 app, I just never bothered to update the description.

And I'm not running on consumption, the cost isn't the problem, it's abuse that impacts others.

[xmedeko]

IMO you can start with rate limiting, and add access tokens later. The free public service should be for manual testing only. If someone wants to use it in automatic tests, then (s)he should run own instance.

[aaronpowell]

The first bit of work on this is done now with #140