ConcurrentRateLimit modify server response code

Not applicable

Here is the example policy. It works fine for 200 responses. Every time the server send back to client 400 or 404 for example(Content-Length -> 0), the response code converted to 503, available count around 200. Why policy changes the response code(this affects the API behavior) and how to make sure, the policy not changing it, and client receives 404 when 404 is expected?

<AlwaysEnforce>false</AlwaysEnforce> or <AlwaysEnforce>true</AlwaysEnforce>
concurrent-rev5-2017-02-09.zipserverresponse404.pngsenttoclient.pngnextstep.png

Is there is a simple/generic solution to override this sort of behaviour?

Solved Solved
1 5 286
1 ACCEPTED SOLUTION

Great Question @ivankatliarchuk , Thank you for bringing this to notice. I can able to reproduce same with your proxy. It's definitely a bug in the product. I will follow up with Engineering team for a fix. I just bumped up the priority of the issue & We will keep you posted. Please see the workaround for now below.

Remember, It's a best practice to attach concurrent rate limit policy to request, response as well as fault rule (Error flow) ? Looks like concurrent rate limit in fault rule is not working as expected.

Just to work around this issue, Add a condition to the default fault rule concurrent rate limit policy step so that it never executes. I just added a dummy condition like below so that it never executes in error flow to avoid above error.

    <DefaultFaultRule name="default-fault">
        <AlwaysEnforce>true</AlwaysEnforce>
        <Step>
            <Name>Concurrent-Rate-Limit-1</Name>
            <Condition>(response.status.code = '')</Condition>
        </Step>
    </DefaultFaultRule>

You might be wondering what happens to the counter if it never executes in response / error flow ? Remember the ttl attribute that you set in concurrent rate limit policy ? It anyways decrements the counter after certain time. So, We should be good for time being.

Hope above work around helps & we will keep you posted. @arghya das , I see you reported this issue earlier. How can we prioritize this & whom should we talk to ?

View solution in original post

5 REPLIES 5

Not applicable

Great Question @ivankatliarchuk , Thank you for bringing this to notice. I can able to reproduce same with your proxy. It's definitely a bug in the product. I will follow up with Engineering team for a fix. I just bumped up the priority of the issue & We will keep you posted. Please see the workaround for now below.

Remember, It's a best practice to attach concurrent rate limit policy to request, response as well as fault rule (Error flow) ? Looks like concurrent rate limit in fault rule is not working as expected.

Just to work around this issue, Add a condition to the default fault rule concurrent rate limit policy step so that it never executes. I just added a dummy condition like below so that it never executes in error flow to avoid above error.

    <DefaultFaultRule name="default-fault">
        <AlwaysEnforce>true</AlwaysEnforce>
        <Step>
            <Name>Concurrent-Rate-Limit-1</Name>
            <Condition>(response.status.code = '')</Condition>
        </Step>
    </DefaultFaultRule>

You might be wondering what happens to the counter if it never executes in response / error flow ? Remember the ttl attribute that you set in concurrent rate limit policy ? It anyways decrements the counter after certain time. So, We should be good for time being.

Hope above work around helps & we will keep you posted. @arghya das , I see you reported this issue earlier. How can we prioritize this & whom should we talk to ?

Hi @Anil Sagar,

Is this issue fixed post 17.01 release?

@Sadiq Hussain

Unfortunately, Not yet. We are following up with Engineering Team. I will keep you posted if any updates.

Hi

Has the issue been fixed?

@Anil Sagar @arghya das