AnsweredAssumed Answered

HTTP connector auto-decompressing gzip responses sometimes?

Question asked by GuinScholl3001 on Mar 15, 2017
Latest reply on Apr 13, 2017 by GuinScholl3001


I'm wondering if anyone has seen any inconsistent behavior with how the HTTP connector is processing responses where an "ACCEPT-ENCODING: gzip, deflate" response header is specified?    We have had jobs for 3-4 years that receive responses from one of our providers in compressed format.  We have a Scripting component that unzips the results.   This has worked for years.    In the last month or so we are getting more and more sporadic results where the documents are already decompressed which then causes the job to fail because the document is already decompressed.


Below are two executions of the exact same job 30 seconds apart.  The provider (who's API call we are making) swears that they are always returning the results in gzip format.   In Boomi however, in one execution the document is compressed, and in the other the document arrives apparently already decompressed.


In this first execution, the document arrives in gzip format and the job works normally.


And in this execution (30 seconds later) the document arrives already decompressed in text/xml format. Which of course causes the scripting step to fail



I wonder if the HTTP connector is sometimes "auto decompressing" responses?


Thanks for any insight anyone can provide.