Replies: 2 comments 8 replies
-
\CC @mkouba |
Beta Was this translation helpful? Give feedback.
0 replies
-
@aylwyne Are you using the RESTEasy Classic extension ( While reading our docs it seems that the If you were using Quarkus REST I'd recommend you to simply annotate your resource method with |
Beta Was this translation helpful? Give feedback.
8 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a service built on RestEasy Classic. This service has
quarkus.resteasy.gzip.enabled = true
and most REST resources return JSON and use the@GZIP
annotation to automatically compress the responses.I am now trying to integrate with a backend that is returning to me an already GZIPped data stream and I want to be able to return that from a Quarkus REST endpoint without unzipping it.
I am struggling with getting this to work. It seems I get double-gzipped responses. I have a REST resource without the
@GZIP
annotation. I have tried a basic test with the following method in my resource:The number of bytes of the gzipped
baos
is 33 yet this results in 49 bytes returned. If I remove the.encoding("gzip")
then I correctly get back 33 bytes but without thecontent-encoding
header so the browser doesn't unzip it. However if I manually unzip that 33 bytes I do get the expected JSON.So it seems like Quarkus is also doing its automatic gzipping on top of my own due to the
quarkus.resteasy.gzip.enabled
config.Is there a way to have an endpoint return an already gzipped byte array unmodified?
Also, I did test with
quarkus.resteasy.gzip.enabled = false
and the above code works as expected. So I guess it boils down to needing to mix automatically gzipped endpoints with manually gzipped ones.Beta Was this translation helpful? Give feedback.
All reactions