unleashed
commented
3 years ago Note that here we clash with the scope of these fields. Do they refer to the current request which for whatever reason ends up in a redirection or do they refer to the request that will follow up to the target location?
We have been careful to always talk about the current request and leave the scope undefined but one way or another contained in this request (ie. the same service, the same path prefix, the same domain, the same hour, or any other criteria that can emerge from the fact we are performing this particular request). With the fields applied to the follow up redirection this could change, because the target location could be any URL.
So what would happen if we really wanted to limit the endpoint that causes the redirection instead of the target location? A point can be made about these values being of no use when an endpoint is redirected, but if the redirection was conditional or temporary, we'd lose the ability to convey these limits. In addition, a redirect might target a different service altogether, potentially with its own policies this service might know nothing about.
I think giving a different meaning to these values in the case of redirection creates an exception that does not carry enough weight. In the general case where a redirection is permanent, you can simply assume as a client that you need to call at least once the target location in order to obtain rate limiting information. After all, your request was serviced, not refused, so if the target was under the control of this service and it determined that you have no quota, it could just as well refuse to respond with the redirect and instead send back a 429 or some other client error status rather than waiting for you to perform another request only to then refuse to service it.
ioggstream
darrelmiller
This PR