Skip to content
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

feat: dispatch OPTIONS requests #10011

Merged
merged 13 commits into from
Nov 10, 2023
Merged

feat: dispatch OPTIONS requests #10011

merged 13 commits into from
Nov 10, 2023

Conversation

sdelamo
Copy link
Contributor

@sdelamo sdelamo commented Oct 23, 2023

It adds micronaut.server.dispatch-options-requests configuration setting which by default is false. If set to true, an OPTION request, unless it is a CORS Preflight request, returns 204 and the Allow HTTP Header populated.

Spring Boot 3.1. by default setsspring.mvc.dispatch-options-request to true and it behaves the same way as we will in this PR. Spring Boot returns 200, I returned 204 which I think it is more correct.

Add micronaut.server.dispatch-options-requests configuration setting which by default is false
@sdelamo sdelamo added the type: enhancement New feature or request label Oct 23, 2023
@sdelamo
Copy link
Contributor Author

sdelamo commented Oct 23, 2023

@yawkat @graemerocher @dstepanov let me know if you agree with this PR and I will add more docs.

if (request.getMethod() != HttpMethod.OPTIONS) {
return null; // proceed
}
if (CorsUtil.isPreflightRequest(request)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be better to run the CORS filter first instead of this check.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added a commit to ensure the CorsFilter happens before the Optionsfilter. However, I think it is more correct to leave this if check in place.

@yawkat
Copy link
Member

yawkat commented Oct 24, 2023

this essentially hijacks all our options processing? that seems wrong

@yawkat
Copy link
Member

yawkat commented Oct 24, 2023

also 200 is better here, cant actually say what content length will be returned by GET

@sdelamo
Copy link
Contributor Author

sdelamo commented Oct 24, 2023

this essentially hijacks all our options processing? that seems wrong

what "Option processing" are we currently doing?

@sdelamo
Copy link
Contributor Author

sdelamo commented Oct 24, 2023

also 200 is better here, cant actually say what content length will be returned by GET

if the response has no content as in this PR, I think a 204 is more correct.

@yawkat
Copy link
Member

yawkat commented Oct 24, 2023

i mixed up HEAD and OPTIONS, both my points don't apply to OPTIONS.

@dstepanov
Copy link
Contributor

dstepanov commented Oct 24, 2023

@sdelamo Jonas is right, what if somebody defines the OPTIONS methods manually? How do we handle the same scenario with HEAD?

@sdelamo
Copy link
Contributor Author

sdelamo commented Oct 24, 2023

@sdelamo Jonas is right; what if somebody defines the OPTIONS methods manually? How do we handle the same scenario with HEAD?

Do you mean if someone annotates a controller method with @Options? We don't have any test of that in our codebase. The @Options annotation only appears in the docs ;-)

I can modify the filter and check for a route match, and if there is a route match, proceed. I assume a route match will happen when you have a @controller method annotated with @Options. Will that fulfill your concerns? @dstepanov

@dstepanov
Copy link
Contributor

Sound good, please test the HEAD use case as well

@sdelamo
Copy link
Contributor Author

sdelamo commented Oct 24, 2023

Sound good, please test the HEAD use case as well

Please, note this filter proceeds if the request methods is other than option

@sdelamo
Copy link
Contributor Author

sdelamo commented Oct 25, 2023

@sdelamo Jonas is right; what if somebody defines the OPTIONS methods manually? How do we handle the same scenario with HEAD?

Do you mean if someone annotates a controller method with @Options? We don't have any test of that in our codebase. The @Options annotation only appears in the docs ;-)

I can modify the filter and check for a route match, and if there is a route match, proceed. I assume a route match will happen when you have a @controller method annotated with @Options. Will that fulfill your concerns? @dstepanov

@dstepanov I added it here 2f54ebe

----
micronaut:
server:
dispatch-options-requests: true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be under CorsConfigration

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's doesn't need to related to CORS, Spring MVC has it the sam way

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not related to CORS or necessary for CORS.

@sdelamo sdelamo added this to the 4.2.0 milestone Nov 10, 2023
Copy link

sonarcloud bot commented Nov 10, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

89.5% 89.5% Coverage
0.0% 0.0% Duplication

@sdelamo sdelamo merged commit 9c2454f into 4.2.x Nov 10, 2023
16 checks passed
@sdelamo sdelamo deleted the dispatch-options branch November 10, 2023 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants