Change response code returned to client when they are over limits about apicast HOT 7 CLOSED

This is a duplicate of #368

from apicast.

I am all for improving this, but I would prefer to take a bit more time and do a proper implementation with the ability to customize the response. The code to handle that was designed in a good extensible manner. The second phase beyond that would be to provide meta data response to the client about the rate limit and the time remaining until the next window.

from apicast.

I agree we can wait. Especially as it seems we can use the X-3scale header that will be supported according to @unleashed. This should cover most scenarios in the meantime.

from apicast.

OK.

Will the X-3scale be documented in the trouble-shooting guide. I see this behavior as a trouble-shooting problem for providers....

from apicast.

Once it is supported and documented it makes sense to document it also in the troubleshooting guide.

from apicast.

The response header referred by @kevprice83 would be (with the corresponding value):

3scale-rejection-reason: limits_exceeded

For this to work the gateway will need to provide a header in its request to backend with the following form:

3scale-options: rejection_reason_header=1

and if it not parsing the body, use instead:

3scale-options: no_body=1&rejection_reason_header=1

This needs to wait until deployment of the affected backend version, which we are working towards completing today (or given the current time, probably on Monday).

from apicast.

Just chipping it to say that the deployment of support for that header happened a while ago.

from apicast.