1

We have an Azure Api Management instance behind a Cloudflare firewall. Recently we got a report of a client getting an error on a POST to the backend API.

It turned out issue was that the request was compressed (content-encoding gzip) and as the body partially contained base64 encoded stuff, the Cloudflare firewall identified that as a threat thus blocking it.

We have several options to address this, but the first option would be to see whether we can address this in APIM as different (mobile) clients sending in gzipped content will have this issue.

The most ideal solution would be to intercept some negotiation on compression, where we could just return false on that request. However I was unable to find such thing and I'm not sure about the impact on the clients.

Are there any other options we have in APIM to force clients not to send in gzip compressed requests?

Jean-Paul Smit
  • 300
  • 4
  • 17

1 Answers1

1

Use set-header policy to set value of Content-Encoding header as appropriate. It will trigger internal logic in APIM to decompress/compress request content. Do that in inbound section to change request coming to backend, in outbound to change response to client.

Vitaliy Kurokhtin
  • 7,205
  • 1
  • 19
  • 18
  • Thanks Vitaliy. The issue here is that APIM is behind the Cloudflare firewall, so the request doesn't even end up in APIM. I was hoping there was some content negotiation going on which I could intercept, but I don't think that is happening, right? – Jean-Paul Smit Feb 20 '20 at 10:27
  • There is no explicit encoding negotiation between client (browser) and api (server) unfortunatelly. Client just sends encoded data, server is free to response 415 to indicate that encoding is not supported, logic to reissue request without encoding must be implemented on client, and I'm not sure if modern browsers are capable of that. Is your client a browser? Do you control its logic? – Vitaliy Kurokhtin Feb 21 '20 at 01:07
  • Thanks again, my clients are mobile apps so not that easy to adjust. I think I'm going to try to fix it in the WAF. Actually I'm surprised that a gzipped request is blocked while the same request deflated it accepted. WAF is able to decompress it so should come to the same conclusion, regardless of the compression. – Jean-Paul Smit Feb 21 '20 at 07:59
  • I'm accessing CosmosDB via API Management and wanted to compress the output with the `gzip` policy (placed in the operations' outbound policy). Unfortunately, there is absolutely no difference in Content-Length or size. Is there something I'm missing? I've also tried: _compressed_ and _br_ but nothing seems to compress the response. – DSpirit Nov 24 '20 at 16:05
  • How do you check response size? Data may be decompressed implicitly and you just don't notice it. – Vitaliy Kurokhtin Nov 24 '20 at 23:07
  • @DSpirit Do you have any updates regarding the outbound compression? for me `gzip` doesn't make any difference as well. – TempoClick Sep 22 '22 at 10:49
  • 2
    @TempoClick I had a call with Microsoft back then and the difference was when checking the result in VSCode REST Client, as it automatically unpacked the response and showed me the full size. You have to check it in a different way, e.g. in C# or others. Unfortunately I didn't test it too detailed, so I'm not really up to date :( – DSpirit Sep 22 '22 at 13:02
  • 1
    I recommend Fiddler for tests like that – Vitaliy Kurokhtin Sep 22 '22 at 17:42