Ratelimit by header value creates keys using cached values

[didip]

Ratelimit by header value creates keys using cached values

[didip]

Man, I keep not getting notified over email.

This does look like a bug. I will take a look at it closer, it has been a while.

[didip]

v4.0.2

[jack-chung]

@didip Yes that's how I see this feature should work, based on the use case I outlined above. Also, this new code still supports the "aggregated limit" use case if needed. Just set the header value to a static value for all users, then it works just like before.

[rvdwijngaard]

I was actually thinking the same; @didip can you please give your comments on this issue?

[jack-chung]

Agreed the headerValues part of the code looks not right. It's not checking the configured values against the request value, and also not using the request value to build the key.

[didip]

This is a legitimate bug, see fix SHA above.

[jack-chung]

@didip For the case of a configured header name with no value, the new code puts the header name into the key but no value. I thought it's supposed to include the header value in the request as part of the key? Or did I misunderstand the intended use case?

Example:
If I want to throttle on a header called X-USER-ID, so that each user is bound by a request limit, this is not going to work with the new code (nor the old code). Only the header name is in the key, so different users coming from the same IP (e.g. behind corporate firewall) would all be subject to the same aggregated limit, not individual limits.

[didip]

@jack-chung If you only define request header (without values) and if everyone visiting has X-USER-ID, then yes, they all limited under the same bucket.

Do you think they should all be limited as individual limit?