-
Notifications
You must be signed in to change notification settings - Fork 3.4k
The OPTIONS request cannot be forwarded to the service #2472
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
Comments
Any plans to fix this soon? |
@DawnSouther Can you propose some quick code fix, please? I'm blocked from this issue. |
Any update on this? |
@spencergibb is it possible to fix this issue soon? Unfortunately it's blocking my project. |
PRs welcome. The earliest release will by next month. |
@rcbandit111 Sorry, just saw this. @Bean
public RoutePredicateHandlerMapping tusRoutePredicateHandlerMapping(FilteringWebHandler webHandler,
RouteLocator routeLocator,
GlobalCorsProperties globalCorsProperties,
Environment environment) {
RoutePredicateHandlerMapping routePredicateHandlerMapping = new RoutePredicateHandlerMapping(webHandler,
routeLocator, globalCorsProperties, environment);
routePredicateHandlerMapping.setCorsProcessor(new TusCorsProcessor());
return routePredicateHandlerMapping;
} |
Before formally solving this problem, I think I should listen to your ideas first, or I just need to mention a pr that ignores the interception of cors in the gateway? |
@DawnSouther I want to test your temporary solution. Can you share what is the content of |
Of course. public class TusCorsProcessor extends DefaultCorsProcessor {
private final AntPathMatcher antPathMatcher = new AntPathMatcher();
@Override
public boolean process(@Nullable CorsConfiguration config, ServerWebExchange exchange) {
// 添加tus头
String contextPath = exchange.getRequest().getURI().getRawPath();
if (!StrUtil.endWith(contextPath, "/")) {
contextPath = contextPath + "/";
}
if (antPathMatcher.match(TusConsts.TUS_PATTERN, contextPath)) {
this.applyTusHeader(exchange.getResponse());
}
return super.process(config, exchange);
}
private void applyTusHeader(ServerHttpResponse response) {
HttpHeaders headers = response.getHeaders();
headers.add(TusConsts.ACCESS_CONTROL_EXPOSE_HEADER, TusConsts.ACCESS_CONTROL_EXPOSE_OPTIONS_VALUE);
headers.add(TusConsts.TUS_RESUMABLE_HEADER, TusConsts.TUS_RESUMABLE_VALUE);
headers.add(TusConsts.TUS_VERSION_HEADER, TusConsts.TUS_VERSION_VALUE);
headers.add(TusConsts.TUS_MAX_SIZE_HEADER, TusConsts.TUS_MAX_SIZE.toString());
headers.add(TusConsts.TUS_EXTENTION_HEADER, TusConsts.TUS_EXTENTION_VALUE);
response.setStatusCode(HttpStatus.OK);
}
} |
@DawnSouther Can you share also what are the imports for this class? I can't find imports for |
@DawnSouther I tried this:
But OPTIONS request is not forwarded again properly. @spencergibb can you also advise please how I can make a quick fix for this issue? |
@rcbandit111 I put the logic to be processed by options on the gateway |
@DawnSouther Sorry I don't get it. Can you show me code example, please? |
I don't have any quick fix for this. The code in your screenshots is from Spring Framework and not Gateway. It looks like we might need a custom CorsProcessor, but I'm not familiar with that bit of framework. I'll need to work with @rstoyanchev |
Thanks, waiting for fix. |
@spencergibb the general idea is that Spring WebFlux has built-in support for pre-flight requests, so it only finds the matching handler for the "would-be" (actual) request, then updates the response accordingly, and shortcircuits. Keep in mind that pre-flight requests are not authenticated. This why they're handled even earlier in Spring Security, which finds a To handle pre-flight requests by passing them through, you'll need some similar approach, intercept early via |
@rstoyanchev Thanks for your explanation. Maybe we can add a switch to it to control the For example, I have a very practical scenario where I need to be a server that supports the I think |
@DawnSouther |
Is there any solution to this problem at the moment? Or how to get around it? |
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
Because I have a service proxied by the gateway, this service needs to customize the response header of the OPTIONS request, but I found that the gateway does not send the request to my service
I found that when the preflight request passes through the gateway, the request header contains both Origin and Access-Control-Request-Method, it will enter NO_OP_HANDLER and will not access the route defined by the RouteDefinition.
Does the cors of the gateway refer to intercepting the request and returning it directly?
If so, is there a way to remove the cors filter of the gateway? Or can you briefly talk about why it is designed like this?
Version
[email protected]
Config
The text was updated successfully, but these errors were encountered: