This is the initial stepping stone for T405544. It enables manual testing and verification of the ratelimiting setup in a production environment, without imposing limits. For this purpose:

• rate limiting should be disabled per default
• rest routes should be able to opt into rate limiting
• the user identity will be taken from the centralauth-user cookie
• rate limiting should be applied only if a spcial header is sete by the client, providing the cuser "class" that determins the rate limits
• rate limiting is implemented using the same Redis backend that we also use to implement rate limiting for api.wikimedia.org

Solution

Ratelimiting is based on the existence of two headers:

• x-wmf-user-id -> a user idenfier
• x-wmf-user-class -> user type, anon or cookie-user at this moment.

The x-wmf-user-id header gets injected by Lua script. Second header x-wmf-user-class will be also injected by Lua script, but currently this logic is commented out and it is expected for the caller to pass this header to remotely enable the rate limitting.

The solution was tested locally, by sending curl -s -H "x-wmf-user-class: anon" localhost:8087/enwiki/v1/page/mobile-html/a/b request gets ratelimited. When sent without the x-wmf-user-class header, the ratelimiting logic is skipped.

At this moment we can easily check the envoy response headers. When the request is goes trough ratelimiting, envoy injects couple headers to the response:

By default we get:

x-ratelimit-limit: 2, 2;w=60
x-ratelimit-remaining: 1
x-ratelimit-reset: 40

And when request is blocked, the response becomes http 429 with

x-envoy-ratelimited: true
x-ratelimit-limit: 2, 2;w=60
x-ratelimit-remaining: 0
x-ratelimit-reset: 12