Forum Discussion
Nimbostratusuncompress gzip REQUEST with JSON
I have a client app that send JSON requests to the server pool.
The requests are compressed with GZIP and I'm sending a Content-Encoding: gzip header.
F5 doesn't seem to uncompress the responses - Policy Builder cannot recognize my JSON data and I get a lot of HTTP compliance errors due to ASM looking at the compressed body instread of uncompressing it.
I couldn't find anything about uncompressing client requests (just an old, unanswered post from 2009). What am I missing? How can I configure ASM (or LTM) to uncompress the data before the policy is enforced?
24 Replies
What_Lies_Bene1Cirrostratus
Sorry but it's not clear what is being compressed (or not) here. Are the requests compressed or the responses? Are the real servers doing the compression? If so, I suspect you'll need to offload that task to the F5 which is no bad thing.
natheCirrocumulus
Avshalom
Have you configured a JSON Content Profile and applied it to a Parameter/URL in the ASM policy? Think this only applies to v11, however. I wonder if this would help at all.
Rgds
N
Avshalom_114801Yeah - configured a JSON profile manually and applied to the URL of the service endpoint - I always get "Malformed JSON". When viewing the request, I see the compressed binary data.
The JSON is definitley well-formed and passes lint tests.
The only explanation I can see is that ASM is not uncompressing the GZIP in the request. I know it can compress/uncompress responses, but I haven't seen anywhere where I can configure it to uncompress requests
Without this functionality, I will have to drop gzip compression, which will greatly impact my app's performance. It seems to defy logic that there isn't such a functionality...
Thanks,
Avshalom
- Avshalom_114801
The CLIENT compresses the REQUESTS sent to the server. right now, I don't care if the server will decompress or F5 - what I'm interseted in, is to apply my ASM policy (parameters, lengths, signatures, etc.) to the JSON payload coming from the CLIENT in the REQUSET.
The problem is that the policy in ASM is not applied to the content bacause ASM only sees the gzip binary data and not the JSON text.
Here is a sample REQUEST, as logged in ASM (header values modified a bit to protect customer info):
POST /endpoint/service/?param1=AAADDD HTTP/1.1
Accept: application/json
Content-type: application/json
Content-Encoding: gzip
User-Agent: CUSTOM
Host: example.com:21499
Connection: Keep-Alive
Content-Length: 12547
Y�Ɇ���Ȼ�|{���>,>6>M�)�ɖɦ����w�(R�UwvV553��bvfB�*o'2O������n�]�}>{wFB�sA�$�N���R��_��_��[��Շ5��b�ݮ~={��y���'�ۿ�����fs�_%1(�������������nu��g����މA������vu;a��z�o7��7�dzw�������?��rs7|~���\߮ReplaceWith?���������~�
Fc0��?������4٘�z�V��TF9��bKƄ��e$�珛����g�AyE�� U!H������M�Ұ����p��_�<<~��<|~�/��\?>�] M���MW��pNAI�CpB��
���,�R��6t�vR��0�ߜ/�u�\|�l>ܮ_����p��ps- Janek_42109
Hello Avshalom,
It seems that I have a same issue. Have you been able to solve this problem ?
Thank you
miss_R_305902I also encountered something similar. The response you have is a binary. It is not a valid gzip.
Let's suppose
is the ByteArrayOutputStream used by your GZIPOutputStream. Encode your output to Base64 like this :out
Then your response will be unzippable.String compressedResponse = Base64.getEncoder().encodeToString( out.toByteArray() );
I hope this helps !
- Avshalom_114801
- What_Lies_Bene1I'm afraid I'm not familiar with ASM but perhaps you can move the compression to the F5? Still, I've never seen client request compression in use on LTM but I'd assume it's supported.
- Avshalom_114801
That's the funny thing - everyone I talked to also says that they "assume it's supported" or that they're sure it's "supposed to be an option on the profile", but nobody can tell where to configure it... :)
It seems almost trivial that there should be such an option, but where is it?
- What_Lies_Bene1Hmmm. I've trawled through all the F5 docs I can find and there's just no mention. I've also given RFCC2616 a once over and there's no mention of request compression that I can see I'm afraid.
- What_Lies_Bene1Btw, are you using Apache at the server side?
- Avshalom_114801No - using EngineX. How will the backend server have any effect on this?
