-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
LambdaHttpHandler does not properly handle multiple Accept headers #21559
Comments
I could not reproduce this problem at all. What version of Quarkus are you using? |
This came about while trying to reproduce the problem mentioned in quarkusio#21559
Hi, we are using Quarkus 2.3.1 Maven pom.xml:
|
Can you try with Quarkus 2.5.0.Final please? |
Sure, your question prompted me to check the latest version and I just noticed that 2.5 has just been released ;-) |
TLDR - upgrading to Quarkus 2.5.0 hasn't helped, sorry about that. Result with version 2.3.1 when passing application/xml as the first accept header:
Result with 2.3.1 when switching the accept headers around:
And then with Quarkus 2.5.0
reversing the order of the accept headers:
|
Output from mvn quarkus:dev to confirm the version
|
Can you attach a sample project that exhibits this behavior? |
The test application here is basically a wrapper for a different web service - we use the RestEasy Client to call the remote project, I am just wondering if there is some unexpected interaction between RestEasy and the client? |
THis looks like a resteasy reactive issue. |
Good point - I didn't see that RR was being used, so I'll give it another pass. |
Turned out it was a RESTEasy Reactive issue after all. |
This came about while trying to reproduce the problem mentioned in quarkusio#21559
Excellent, many thanks for your help! |
Take multiple Accept headers case into account in RESTEasy Reactive
Fixes: quarkusio#21559 (cherry picked from commit 3f1a599)
Scenario:
(Actually the deployment to AWS is not required to reproduce - the problem is still evident locally with mvn quarkus:dev after adding the dependency to quarkus-amazon-lambda-http)
The problem seems to be that LambdaHttpHandler splits the HTTP Accept headers before forwarding to the application:
Original header from the client with multiple accepted media types:
Accept: text/html,application/text,*/*
Request received after LambdaHttpHandler has done its magic:
Accept: text/html
Accept: application/text
Accept: */*
Splitting the accept header into multiple accept headers is OK from a HTTP perspective, but whichever component routes the request to the application appears to only use the first of these headers, so a typical REST service that can only produce application/json then responds with HTTP 406
The problem can be reproduced with non-lambda version as well with curl:
curl 'http://localhost:8080/someRestEndpoint' -H "Accept: application/xml" -H "Accept: application/json" -i -v
Switching the header order fixes or sidesteps the problem, because then application/json is first in the list.
curl 'http://localhost:8080/someRestEndpoint' -H "Accept: application/json" -H "Accept: application/xml" -i -v
The text was updated successfully, but these errors were encountered: