-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no more HTTP compression for resteasy-classic endpoints #26112
Comments
cc @mkouba |
Yes, it's a breaking change as documented in the migration guide. We believe that the original behavior did not make a lot of sense because it enabled compression for every HTTP response. You should annotate your resteasy classic resources with |
@mkouba hmm, the migration guide says nothing about RESTEasy Classic or did I miss something? Also, can you compress all your JSON REST resources served by RESTEasy Classic/Reactive by using |
No, it doesn't and
For RESTEasy Reactive the response is compressed if the |
On Tue, Jun 14, 2022 at 4:32 PM Martin Kouba ***@***.***> wrote:
hmm, the migration guide says nothing about RESTEasy Classic or did I miss
something?
No, it doesn't and quarkus.http.enable-compression did not mention
RESTEasy classic either. It was just an *all or nothing* switch.
Well, it doesn't mention it but if it was a global switch, it affected it.
So we somehow need to document that it's affected?
And we should probably check if `quarkus.http.compress-media-types` works
with RESTEasy Classic as adding @gzip to every REST resource will be a
major pain.
…
Message ID: ***@***.***>
|
FTR this is our RESTEasy Classic documentation about GZip Support (we added a note that
I don't think that it does because we add
It is. On the other hand, the previous behavior of |
I think we really need to test this and I also think we should make the media types configuration work with RESTEasy Classic i.e. have the ability to say: all my JSON content will be gzipped and that would include RESTEasy Classic endpoints returning JSON. TBH I was under the impression that it was done this way. We also need something in the migration guide as the behavior has changed (even if it wasn't documented, we were telling people to use this property when asked). |
In theory, we could add a
It wasn't ;-). The PR description was very clear that |
Thanks for looking into this issue. Based on your comments, I have done some tests from the quarkus-quickstarts/getting-started project in this branch. The file TESTSSUMMARY.md contains the test results I did (please open as raw). Table of the test results:
SummaryIn quarkus 2.9.2.Final, resteasy classic endpoint only serves a compressed response when |
@tnmtechnologies Thanks for the tests! Yes, the results are expected. I believe that |
Well, I think we will probably have to do that. I'm not looking forward to explaining to people that they need to add the In any case, we need to make things clear there for RESTEasy Classic: https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.9#http-compression . Right now, people have no idea that the behavior has changed and they might miss it (until they get their bandwidth bill). Also, probably a good idea to understand what's happening with metrics and why it worked before and doesn't work anymore. |
- honor the quarkus.http.compress-media-types in Undertow Servlet and RESTEasy Classsic extensions - fixes quarkusio#31415 and quarkusio#26112
- honor the quarkus.http.compress-media-types in Undertow Servlet and RESTEasy Classsic extensions - fixes quarkusio#31415 and quarkusio#26112
- honor the quarkus.http.compress-media-types in Undertow Servlet and RESTEasy Classsic extensions - fixes quarkusio#31415 and quarkusio#26112
@mkouba this has been fixed, no? |
Yes! |
Describe the bug
Our REST enpoints are based on resteasy classic mode.
For quarkus 2.8.2.Final, we set quarkus.http.enable-compression=true and responses are well compressed.
After upgrading to quarkus 2.9.0.Final, responses are no more compressed.
Behaviour of quarkus.http.enable-compression property has been changed in quarkus 2.9.0.Final.
Expected behavior
Be able to serve compressed responses in resteasy classic mode
Actual behavior
For quarkus 2.9.0.Final and for resteasy classic mode, responses are no more compressed when property quarkus.http.enable-compression=true.
How to Reproduce?
Having a REST service with
and serving a response with for instance a application/json or application/xml content type
Output of
uname -a
orver
No response
Output of
java -version
No response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
No response
Build tool (ie. output of
mvnw --version
orgradlew --version
)No response
Additional information
In #24558 (comment), we can read:
Note that it's a breaking change in the sense that previously quarkus.http.enable-compression=true enabled compression for every HTTP response which is not the case anymore. The configuration property is effectively ignored for reasteasy-classic endpoints and routes registered manually.
The text was updated successfully, but these errors were encountered: