[WIP] 70 throttling scope

[ioggstream]

This PR

Defines a throttling scope using parameters.

[unleashed]

When I think about rate limiting scoping I identify three potential sources of information: data attached to the request, data attached to the resource, and data attached to the environment in which an HTTP transaction happens (ie. service configuration, network, etc). The three of them could provide input to the rate limiting policy.

• The first category would include all the information present in an HTTP request, including headers, trailers, body, and of course specifics about the URI, scheme, host, path, query string, etc, but also networking information such as the source and destination addresses, protocol version, advertised client, etc.
• The second category would refer to the cost of returning the resource. A couple of simple examples would be sourcing content from a third party that incurs in fees or transforming the resource representation to match the request's Accept header.
• The third category would include things that are not related to the specific resource being accessed nor to the request or its origin. This would match for example computing or networking resources' exhaustion, infrastructure configuration (ie. number of connections), day of the week, etc.

When providing information to clients about what a quota applies to, these distinctions might come in handy to add context, rather than just mapping the limits to the requested URI and trying it out again hoping for the best. In some cases there would be obvious benefits to the client if the policy applied could pinpoint the cause for the rate limiting, such as some transient issue or a static configuration. For example, it would be reasonable for a client to avoid any further requests if the reason for a complete limitation would be its source IP address.

Would it be interesting to dig into this level of detail? Perhaps it is a lot of ground to cover and best left to extensions?