Unfortunately, ratelimit is a bit of a blunt instrument -- it assumes that anything with at least two components to the path will correspond to a Swift path, regardless of whether the first component is a valid api version (like v1) or not (like auth). Unfortunately, this gets more complicated when you need to consider ratelimit's placement with respect to cname_lookup, domain_remap, or swift3 middlewares; as a result I'm not even sure that the current, rather broad behavior covers *enough* cases.
Fortunately, though, the errors are benign and can just be ignored. I think it's pretty safe to ignore *any* 4xx error with a RL source.
(Separately, though, I think tempauth is out of spec returning a 400 on HEAD where a GET would 401... never mind the fact that there's a better code (405) for exactly this situation of using the wrong method on a known path...)
Unfortunately, ratelimit is a bit of a blunt instrument -- it assumes that anything with at least two components to the path will correspond to a Swift path, regardless of whether the first component is a valid api version (like v1) or not (like auth). Unfortunately, this gets more complicated when you need to consider ratelimit's placement with respect to cname_lookup, domain_remap, or swift3 middlewares; as a result I'm not even sure that the current, rather broad behavior covers *enough* cases.
Fortunately, though, the errors are benign and can just be ignored. I think it's pretty safe to ignore *any* 4xx error with a RL source.
See also: https:/ /bugs.launchpad .net/swift/ +bug/1669888
(Separately, though, I think tempauth is out of spec returning a 400 on HEAD where a GET would 401... never mind the fact that there's a better code (405) for exactly this situation of using the wrong method on a known path...)