JAX-RX - Blocked by CORS policy: Method PATCH is not allowed by Access-Control-Allow-Methods in preflight...











up vote
0
down vote

favorite












I am using Spring boot with Jersey 2.1



and Ionic to develop an App, I've tried every single post I've found but none solved this problem for me the error I am getting, including those which say about creating the @PATCH interface annotation yourself.



So, the thing is I am getting this error on the client side when testing on the browser when doing a PATCH request:




Access to XMLHttpRequest at '' from origin 'http://localhost:8100' has
been blocked by CORS policy: Method PATCH is not allowed by
Access-Control-Allow-Methods in preflight response.




The filters I have for the response is the following, I don't understand why I'm getting this if I have PATCH as an allowed method and it works perfectly on Postman:



Filter:



@Provider
public final class ResponseFilter implements ContainerResponseFilter {

@Override
public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
MultivaluedMap<String, Object> headers = responseContext.getHeaders();

headers.putSingle("Accept-Patch", "*");
headers.putSingle("Access-Control-Allow-Origin", "*");
headers.putSingle("Access-Control-Allow-Methods", "POST, PUT, GET, OPTIONS, DELETE, PATCH");
headers.putSingle("Access-Control-Allow-Credentials", "true");
headers.putSingle("Access-Control-Max-Age", "3600");
headers.putSingle("Access-Control-Allow-Headers", "Content-Type, Accept, Authorization");
}
}


Method which uses PATCH:



import javax.ws.rs.PATCH;


@PATCH
@Path("/{username}")
@Produces(MediaType.APPLICATION_JSON)
public Response actualizarPassword(@Valid @NotNull(message = "user must not be null") final UserDTO userDTO,
@PathParam("username") final String username,
@QueryParam("codigo") @NotNull(message = "codigo musnt be null") final String codigo) {
userDTO.setUsername(username);
this.usersService.actualizarPassword(this.userDTOMapper.map(userDTO), codigo);

return Response.noContent().build();
}


As I said, I also tried to create an annotation with PATCH as I read in some answers but this http method is supposed to be included on Jersey 2.1 and it indeed is as it can be see in the previous piece of code, the interface I created was:



@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@HttpMethod("PATCH")
public @interface PATCH {
}


And if I do a POSTMAN request, these are the headers I get:



Accept-Patch →*
Access-Control-Allow-Origin →*
Access-Control-Allow-Methods →POST, PUT, GET, OPTIONS, DELETE, PATCH
Access-Control-Allow-Credentials →true
Access-Control-Max-Age →3600
Access-Control-Allow-Headers →Content-Type, Accept, Authorization
X-Content-Type-Options →nosniff
X-XSS-Protection →1; mode=block
Cache-Control →no-cache, no-store, max-age=0, must-revalidate
Pragma →no-cache
Expires →0
X-Frame-Options →DENY
Content-Type →application/json
Content-Length →54
Date →Wed, 07 Nov 2018 07:46:45 GMT


And incase it's somehow related, this is my SpringSecurity config:



@Configuration
@EnableWebSecurity
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests().anyRequest().permitAll()
.and()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.csrf().disable();
}

@Override
public void configure(WebSecurity web ) throws Exception
{
web.ignoring().antMatchers( HttpMethod.OPTIONS, "/**" );
}
}


UPDATE 1



I've printed the code that the response has and I get a 200. However, I keep getting this error.



UPDATE 2



As requested by sideshowbarker, I made an OPTIONS request with POSTMAN and this is the headers:



Allow →HEAD,GET,OPTIONS,PUT,PATCH
Last-modified →Wed, 07 Nov 2018 10:07:57 GMT+01:00
Accept-Patch →*
Access-Control-Allow-Origin →*
Access-Control-Allow-Methods →POST, PUT, GET, OPTIONS, DELETE, PATCH
Access-Control-Allow-Credentials →true
Access-Control-Max-Age →3600
Access-Control-Allow-Headers →Content-Type, Accept, Authorization
Content-Type →application/vnd.sun.wadl+xml
Content-Length →1165
Date →Wed, 07 Nov 2018 09:07:57 GMT


UPDATE 3



I checked the headers in dev tools as suggested by and the PATCH method isn't there. Why is this? Why is it there if I use POSTMAN but not with my Ionic App?



enter image description here



Please help, I've been struggling with this for days...



Thanks










share|improve this question




















  • 1




    Try testing Postman with an OPTIONS request. Because your browser isn’t actually ever getting around to trying the PATCH request from your frontend code. The browser first does a CORS preflight OPTIONS request, and that fails. So you need to figure out how to configure your Spring backend to respond to the CORS preflight OPTIONS request in the way that the browser needs in order to consider it a success. So you may want to spend some time looking through stackoverflow.com/search?q=%5Bcors%5D+%5Bspring%5D+options or stackoverflow.com/search?q=%5Bcors%5D+%5Bspring-boot%5D+options
    – sideshowbarker
    Nov 7 at 8:49












  • done, I put the response in the 2nd update @sideshowbarker
    – Wrong
    Nov 7 at 9:11






  • 1




    The response body for the OPTIONS response isn’t relevant to the question. In fact that OPTIONS response shouldn’t have a response body. You need to examine the HTTP response headers for the OPTIONS response. And you should actually do that in browser devtools, not with Postman. But I guess you could start by checking the headers with Postman.
    – sideshowbarker
    Nov 7 at 9:31










  • I've updated the 'update 2' @sideshowbarker
    – Wrong
    Nov 7 at 9:33






  • 1




    You really want to use the Network pane in browser devtools to check the response — both the response headers and the HTTP status code of the response. If the browser were getting the same response as what you show you’re getting from Postman, then the browser wouldn’t be reporting that “Method PATCH is not allowed by Access-Control-Allow-Methods in preflight response” message.
    – sideshowbarker
    Nov 7 at 10:41















up vote
0
down vote

favorite












I am using Spring boot with Jersey 2.1



and Ionic to develop an App, I've tried every single post I've found but none solved this problem for me the error I am getting, including those which say about creating the @PATCH interface annotation yourself.



So, the thing is I am getting this error on the client side when testing on the browser when doing a PATCH request:




Access to XMLHttpRequest at '' from origin 'http://localhost:8100' has
been blocked by CORS policy: Method PATCH is not allowed by
Access-Control-Allow-Methods in preflight response.




The filters I have for the response is the following, I don't understand why I'm getting this if I have PATCH as an allowed method and it works perfectly on Postman:



Filter:



@Provider
public final class ResponseFilter implements ContainerResponseFilter {

@Override
public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
MultivaluedMap<String, Object> headers = responseContext.getHeaders();

headers.putSingle("Accept-Patch", "*");
headers.putSingle("Access-Control-Allow-Origin", "*");
headers.putSingle("Access-Control-Allow-Methods", "POST, PUT, GET, OPTIONS, DELETE, PATCH");
headers.putSingle("Access-Control-Allow-Credentials", "true");
headers.putSingle("Access-Control-Max-Age", "3600");
headers.putSingle("Access-Control-Allow-Headers", "Content-Type, Accept, Authorization");
}
}


Method which uses PATCH:



import javax.ws.rs.PATCH;


@PATCH
@Path("/{username}")
@Produces(MediaType.APPLICATION_JSON)
public Response actualizarPassword(@Valid @NotNull(message = "user must not be null") final UserDTO userDTO,
@PathParam("username") final String username,
@QueryParam("codigo") @NotNull(message = "codigo musnt be null") final String codigo) {
userDTO.setUsername(username);
this.usersService.actualizarPassword(this.userDTOMapper.map(userDTO), codigo);

return Response.noContent().build();
}


As I said, I also tried to create an annotation with PATCH as I read in some answers but this http method is supposed to be included on Jersey 2.1 and it indeed is as it can be see in the previous piece of code, the interface I created was:



@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@HttpMethod("PATCH")
public @interface PATCH {
}


And if I do a POSTMAN request, these are the headers I get:



Accept-Patch →*
Access-Control-Allow-Origin →*
Access-Control-Allow-Methods →POST, PUT, GET, OPTIONS, DELETE, PATCH
Access-Control-Allow-Credentials →true
Access-Control-Max-Age →3600
Access-Control-Allow-Headers →Content-Type, Accept, Authorization
X-Content-Type-Options →nosniff
X-XSS-Protection →1; mode=block
Cache-Control →no-cache, no-store, max-age=0, must-revalidate
Pragma →no-cache
Expires →0
X-Frame-Options →DENY
Content-Type →application/json
Content-Length →54
Date →Wed, 07 Nov 2018 07:46:45 GMT


And incase it's somehow related, this is my SpringSecurity config:



@Configuration
@EnableWebSecurity
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests().anyRequest().permitAll()
.and()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.csrf().disable();
}

@Override
public void configure(WebSecurity web ) throws Exception
{
web.ignoring().antMatchers( HttpMethod.OPTIONS, "/**" );
}
}


UPDATE 1



I've printed the code that the response has and I get a 200. However, I keep getting this error.



UPDATE 2



As requested by sideshowbarker, I made an OPTIONS request with POSTMAN and this is the headers:



Allow →HEAD,GET,OPTIONS,PUT,PATCH
Last-modified →Wed, 07 Nov 2018 10:07:57 GMT+01:00
Accept-Patch →*
Access-Control-Allow-Origin →*
Access-Control-Allow-Methods →POST, PUT, GET, OPTIONS, DELETE, PATCH
Access-Control-Allow-Credentials →true
Access-Control-Max-Age →3600
Access-Control-Allow-Headers →Content-Type, Accept, Authorization
Content-Type →application/vnd.sun.wadl+xml
Content-Length →1165
Date →Wed, 07 Nov 2018 09:07:57 GMT


UPDATE 3



I checked the headers in dev tools as suggested by and the PATCH method isn't there. Why is this? Why is it there if I use POSTMAN but not with my Ionic App?



enter image description here



Please help, I've been struggling with this for days...



Thanks










share|improve this question




















  • 1




    Try testing Postman with an OPTIONS request. Because your browser isn’t actually ever getting around to trying the PATCH request from your frontend code. The browser first does a CORS preflight OPTIONS request, and that fails. So you need to figure out how to configure your Spring backend to respond to the CORS preflight OPTIONS request in the way that the browser needs in order to consider it a success. So you may want to spend some time looking through stackoverflow.com/search?q=%5Bcors%5D+%5Bspring%5D+options or stackoverflow.com/search?q=%5Bcors%5D+%5Bspring-boot%5D+options
    – sideshowbarker
    Nov 7 at 8:49












  • done, I put the response in the 2nd update @sideshowbarker
    – Wrong
    Nov 7 at 9:11






  • 1




    The response body for the OPTIONS response isn’t relevant to the question. In fact that OPTIONS response shouldn’t have a response body. You need to examine the HTTP response headers for the OPTIONS response. And you should actually do that in browser devtools, not with Postman. But I guess you could start by checking the headers with Postman.
    – sideshowbarker
    Nov 7 at 9:31










  • I've updated the 'update 2' @sideshowbarker
    – Wrong
    Nov 7 at 9:33






  • 1




    You really want to use the Network pane in browser devtools to check the response — both the response headers and the HTTP status code of the response. If the browser were getting the same response as what you show you’re getting from Postman, then the browser wouldn’t be reporting that “Method PATCH is not allowed by Access-Control-Allow-Methods in preflight response” message.
    – sideshowbarker
    Nov 7 at 10:41













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I am using Spring boot with Jersey 2.1



and Ionic to develop an App, I've tried every single post I've found but none solved this problem for me the error I am getting, including those which say about creating the @PATCH interface annotation yourself.



So, the thing is I am getting this error on the client side when testing on the browser when doing a PATCH request:




Access to XMLHttpRequest at '' from origin 'http://localhost:8100' has
been blocked by CORS policy: Method PATCH is not allowed by
Access-Control-Allow-Methods in preflight response.




The filters I have for the response is the following, I don't understand why I'm getting this if I have PATCH as an allowed method and it works perfectly on Postman:



Filter:



@Provider
public final class ResponseFilter implements ContainerResponseFilter {

@Override
public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
MultivaluedMap<String, Object> headers = responseContext.getHeaders();

headers.putSingle("Accept-Patch", "*");
headers.putSingle("Access-Control-Allow-Origin", "*");
headers.putSingle("Access-Control-Allow-Methods", "POST, PUT, GET, OPTIONS, DELETE, PATCH");
headers.putSingle("Access-Control-Allow-Credentials", "true");
headers.putSingle("Access-Control-Max-Age", "3600");
headers.putSingle("Access-Control-Allow-Headers", "Content-Type, Accept, Authorization");
}
}


Method which uses PATCH:



import javax.ws.rs.PATCH;


@PATCH
@Path("/{username}")
@Produces(MediaType.APPLICATION_JSON)
public Response actualizarPassword(@Valid @NotNull(message = "user must not be null") final UserDTO userDTO,
@PathParam("username") final String username,
@QueryParam("codigo") @NotNull(message = "codigo musnt be null") final String codigo) {
userDTO.setUsername(username);
this.usersService.actualizarPassword(this.userDTOMapper.map(userDTO), codigo);

return Response.noContent().build();
}


As I said, I also tried to create an annotation with PATCH as I read in some answers but this http method is supposed to be included on Jersey 2.1 and it indeed is as it can be see in the previous piece of code, the interface I created was:



@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@HttpMethod("PATCH")
public @interface PATCH {
}


And if I do a POSTMAN request, these are the headers I get:



Accept-Patch →*
Access-Control-Allow-Origin →*
Access-Control-Allow-Methods →POST, PUT, GET, OPTIONS, DELETE, PATCH
Access-Control-Allow-Credentials →true
Access-Control-Max-Age →3600
Access-Control-Allow-Headers →Content-Type, Accept, Authorization
X-Content-Type-Options →nosniff
X-XSS-Protection →1; mode=block
Cache-Control →no-cache, no-store, max-age=0, must-revalidate
Pragma →no-cache
Expires →0
X-Frame-Options →DENY
Content-Type →application/json
Content-Length →54
Date →Wed, 07 Nov 2018 07:46:45 GMT


And incase it's somehow related, this is my SpringSecurity config:



@Configuration
@EnableWebSecurity
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests().anyRequest().permitAll()
.and()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.csrf().disable();
}

@Override
public void configure(WebSecurity web ) throws Exception
{
web.ignoring().antMatchers( HttpMethod.OPTIONS, "/**" );
}
}


UPDATE 1



I've printed the code that the response has and I get a 200. However, I keep getting this error.



UPDATE 2



As requested by sideshowbarker, I made an OPTIONS request with POSTMAN and this is the headers:



Allow →HEAD,GET,OPTIONS,PUT,PATCH
Last-modified →Wed, 07 Nov 2018 10:07:57 GMT+01:00
Accept-Patch →*
Access-Control-Allow-Origin →*
Access-Control-Allow-Methods →POST, PUT, GET, OPTIONS, DELETE, PATCH
Access-Control-Allow-Credentials →true
Access-Control-Max-Age →3600
Access-Control-Allow-Headers →Content-Type, Accept, Authorization
Content-Type →application/vnd.sun.wadl+xml
Content-Length →1165
Date →Wed, 07 Nov 2018 09:07:57 GMT


UPDATE 3



I checked the headers in dev tools as suggested by and the PATCH method isn't there. Why is this? Why is it there if I use POSTMAN but not with my Ionic App?



enter image description here



Please help, I've been struggling with this for days...



Thanks










share|improve this question















I am using Spring boot with Jersey 2.1



and Ionic to develop an App, I've tried every single post I've found but none solved this problem for me the error I am getting, including those which say about creating the @PATCH interface annotation yourself.



So, the thing is I am getting this error on the client side when testing on the browser when doing a PATCH request:




Access to XMLHttpRequest at '' from origin 'http://localhost:8100' has
been blocked by CORS policy: Method PATCH is not allowed by
Access-Control-Allow-Methods in preflight response.




The filters I have for the response is the following, I don't understand why I'm getting this if I have PATCH as an allowed method and it works perfectly on Postman:



Filter:



@Provider
public final class ResponseFilter implements ContainerResponseFilter {

@Override
public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
MultivaluedMap<String, Object> headers = responseContext.getHeaders();

headers.putSingle("Accept-Patch", "*");
headers.putSingle("Access-Control-Allow-Origin", "*");
headers.putSingle("Access-Control-Allow-Methods", "POST, PUT, GET, OPTIONS, DELETE, PATCH");
headers.putSingle("Access-Control-Allow-Credentials", "true");
headers.putSingle("Access-Control-Max-Age", "3600");
headers.putSingle("Access-Control-Allow-Headers", "Content-Type, Accept, Authorization");
}
}


Method which uses PATCH:



import javax.ws.rs.PATCH;


@PATCH
@Path("/{username}")
@Produces(MediaType.APPLICATION_JSON)
public Response actualizarPassword(@Valid @NotNull(message = "user must not be null") final UserDTO userDTO,
@PathParam("username") final String username,
@QueryParam("codigo") @NotNull(message = "codigo musnt be null") final String codigo) {
userDTO.setUsername(username);
this.usersService.actualizarPassword(this.userDTOMapper.map(userDTO), codigo);

return Response.noContent().build();
}


As I said, I also tried to create an annotation with PATCH as I read in some answers but this http method is supposed to be included on Jersey 2.1 and it indeed is as it can be see in the previous piece of code, the interface I created was:



@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@HttpMethod("PATCH")
public @interface PATCH {
}


And if I do a POSTMAN request, these are the headers I get:



Accept-Patch →*
Access-Control-Allow-Origin →*
Access-Control-Allow-Methods →POST, PUT, GET, OPTIONS, DELETE, PATCH
Access-Control-Allow-Credentials →true
Access-Control-Max-Age →3600
Access-Control-Allow-Headers →Content-Type, Accept, Authorization
X-Content-Type-Options →nosniff
X-XSS-Protection →1; mode=block
Cache-Control →no-cache, no-store, max-age=0, must-revalidate
Pragma →no-cache
Expires →0
X-Frame-Options →DENY
Content-Type →application/json
Content-Length →54
Date →Wed, 07 Nov 2018 07:46:45 GMT


And incase it's somehow related, this is my SpringSecurity config:



@Configuration
@EnableWebSecurity
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests().anyRequest().permitAll()
.and()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.csrf().disable();
}

@Override
public void configure(WebSecurity web ) throws Exception
{
web.ignoring().antMatchers( HttpMethod.OPTIONS, "/**" );
}
}


UPDATE 1



I've printed the code that the response has and I get a 200. However, I keep getting this error.



UPDATE 2



As requested by sideshowbarker, I made an OPTIONS request with POSTMAN and this is the headers:



Allow →HEAD,GET,OPTIONS,PUT,PATCH
Last-modified →Wed, 07 Nov 2018 10:07:57 GMT+01:00
Accept-Patch →*
Access-Control-Allow-Origin →*
Access-Control-Allow-Methods →POST, PUT, GET, OPTIONS, DELETE, PATCH
Access-Control-Allow-Credentials →true
Access-Control-Max-Age →3600
Access-Control-Allow-Headers →Content-Type, Accept, Authorization
Content-Type →application/vnd.sun.wadl+xml
Content-Length →1165
Date →Wed, 07 Nov 2018 09:07:57 GMT


UPDATE 3



I checked the headers in dev tools as suggested by and the PATCH method isn't there. Why is this? Why is it there if I use POSTMAN but not with my Ionic App?



enter image description here



Please help, I've been struggling with this for days...



Thanks







java spring-boot cors jax-rs patch






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 7 at 13:40

























asked Nov 7 at 7:49









Wrong

12210




12210








  • 1




    Try testing Postman with an OPTIONS request. Because your browser isn’t actually ever getting around to trying the PATCH request from your frontend code. The browser first does a CORS preflight OPTIONS request, and that fails. So you need to figure out how to configure your Spring backend to respond to the CORS preflight OPTIONS request in the way that the browser needs in order to consider it a success. So you may want to spend some time looking through stackoverflow.com/search?q=%5Bcors%5D+%5Bspring%5D+options or stackoverflow.com/search?q=%5Bcors%5D+%5Bspring-boot%5D+options
    – sideshowbarker
    Nov 7 at 8:49












  • done, I put the response in the 2nd update @sideshowbarker
    – Wrong
    Nov 7 at 9:11






  • 1




    The response body for the OPTIONS response isn’t relevant to the question. In fact that OPTIONS response shouldn’t have a response body. You need to examine the HTTP response headers for the OPTIONS response. And you should actually do that in browser devtools, not with Postman. But I guess you could start by checking the headers with Postman.
    – sideshowbarker
    Nov 7 at 9:31










  • I've updated the 'update 2' @sideshowbarker
    – Wrong
    Nov 7 at 9:33






  • 1




    You really want to use the Network pane in browser devtools to check the response — both the response headers and the HTTP status code of the response. If the browser were getting the same response as what you show you’re getting from Postman, then the browser wouldn’t be reporting that “Method PATCH is not allowed by Access-Control-Allow-Methods in preflight response” message.
    – sideshowbarker
    Nov 7 at 10:41














  • 1




    Try testing Postman with an OPTIONS request. Because your browser isn’t actually ever getting around to trying the PATCH request from your frontend code. The browser first does a CORS preflight OPTIONS request, and that fails. So you need to figure out how to configure your Spring backend to respond to the CORS preflight OPTIONS request in the way that the browser needs in order to consider it a success. So you may want to spend some time looking through stackoverflow.com/search?q=%5Bcors%5D+%5Bspring%5D+options or stackoverflow.com/search?q=%5Bcors%5D+%5Bspring-boot%5D+options
    – sideshowbarker
    Nov 7 at 8:49












  • done, I put the response in the 2nd update @sideshowbarker
    – Wrong
    Nov 7 at 9:11






  • 1




    The response body for the OPTIONS response isn’t relevant to the question. In fact that OPTIONS response shouldn’t have a response body. You need to examine the HTTP response headers for the OPTIONS response. And you should actually do that in browser devtools, not with Postman. But I guess you could start by checking the headers with Postman.
    – sideshowbarker
    Nov 7 at 9:31










  • I've updated the 'update 2' @sideshowbarker
    – Wrong
    Nov 7 at 9:33






  • 1




    You really want to use the Network pane in browser devtools to check the response — both the response headers and the HTTP status code of the response. If the browser were getting the same response as what you show you’re getting from Postman, then the browser wouldn’t be reporting that “Method PATCH is not allowed by Access-Control-Allow-Methods in preflight response” message.
    – sideshowbarker
    Nov 7 at 10:41








1




1




Try testing Postman with an OPTIONS request. Because your browser isn’t actually ever getting around to trying the PATCH request from your frontend code. The browser first does a CORS preflight OPTIONS request, and that fails. So you need to figure out how to configure your Spring backend to respond to the CORS preflight OPTIONS request in the way that the browser needs in order to consider it a success. So you may want to spend some time looking through stackoverflow.com/search?q=%5Bcors%5D+%5Bspring%5D+options or stackoverflow.com/search?q=%5Bcors%5D+%5Bspring-boot%5D+options
– sideshowbarker
Nov 7 at 8:49






Try testing Postman with an OPTIONS request. Because your browser isn’t actually ever getting around to trying the PATCH request from your frontend code. The browser first does a CORS preflight OPTIONS request, and that fails. So you need to figure out how to configure your Spring backend to respond to the CORS preflight OPTIONS request in the way that the browser needs in order to consider it a success. So you may want to spend some time looking through stackoverflow.com/search?q=%5Bcors%5D+%5Bspring%5D+options or stackoverflow.com/search?q=%5Bcors%5D+%5Bspring-boot%5D+options
– sideshowbarker
Nov 7 at 8:49














done, I put the response in the 2nd update @sideshowbarker
– Wrong
Nov 7 at 9:11




done, I put the response in the 2nd update @sideshowbarker
– Wrong
Nov 7 at 9:11




1




1




The response body for the OPTIONS response isn’t relevant to the question. In fact that OPTIONS response shouldn’t have a response body. You need to examine the HTTP response headers for the OPTIONS response. And you should actually do that in browser devtools, not with Postman. But I guess you could start by checking the headers with Postman.
– sideshowbarker
Nov 7 at 9:31




The response body for the OPTIONS response isn’t relevant to the question. In fact that OPTIONS response shouldn’t have a response body. You need to examine the HTTP response headers for the OPTIONS response. And you should actually do that in browser devtools, not with Postman. But I guess you could start by checking the headers with Postman.
– sideshowbarker
Nov 7 at 9:31












I've updated the 'update 2' @sideshowbarker
– Wrong
Nov 7 at 9:33




I've updated the 'update 2' @sideshowbarker
– Wrong
Nov 7 at 9:33




1




1




You really want to use the Network pane in browser devtools to check the response — both the response headers and the HTTP status code of the response. If the browser were getting the same response as what you show you’re getting from Postman, then the browser wouldn’t be reporting that “Method PATCH is not allowed by Access-Control-Allow-Methods in preflight response” message.
– sideshowbarker
Nov 7 at 10:41




You really want to use the Network pane in browser devtools to check the response — both the response headers and the HTTP status code of the response. If the browser were getting the same response as what you show you’re getting from Postman, then the browser wouldn’t be reporting that “Method PATCH is not allowed by Access-Control-Allow-Methods in preflight response” message.
– sideshowbarker
Nov 7 at 10:41












1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted










Okay I am so idiot that I can't even believe it myself. I was using this plugin for Chrome



which was modifying the headers from the response. Noticed it thanks to @sideshowbarker . It's such an idiot thing but that I bet it might happen to other people too.



Thanks alot @sideshowbarker.






share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














     

    draft saved


    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53185346%2fjax-rx-blocked-by-cors-policy-method-patch-is-not-allowed-by-access-control-a%23new-answer', 'question_page');
    }
    );

    Post as a guest
































    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote



    accepted










    Okay I am so idiot that I can't even believe it myself. I was using this plugin for Chrome



    which was modifying the headers from the response. Noticed it thanks to @sideshowbarker . It's such an idiot thing but that I bet it might happen to other people too.



    Thanks alot @sideshowbarker.






    share|improve this answer



























      up vote
      0
      down vote



      accepted










      Okay I am so idiot that I can't even believe it myself. I was using this plugin for Chrome



      which was modifying the headers from the response. Noticed it thanks to @sideshowbarker . It's such an idiot thing but that I bet it might happen to other people too.



      Thanks alot @sideshowbarker.






      share|improve this answer

























        up vote
        0
        down vote



        accepted







        up vote
        0
        down vote



        accepted






        Okay I am so idiot that I can't even believe it myself. I was using this plugin for Chrome



        which was modifying the headers from the response. Noticed it thanks to @sideshowbarker . It's such an idiot thing but that I bet it might happen to other people too.



        Thanks alot @sideshowbarker.






        share|improve this answer














        Okay I am so idiot that I can't even believe it myself. I was using this plugin for Chrome



        which was modifying the headers from the response. Noticed it thanks to @sideshowbarker . It's such an idiot thing but that I bet it might happen to other people too.



        Thanks alot @sideshowbarker.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 7 at 14:05

























        answered Nov 7 at 13:59









        Wrong

        12210




        12210






























             

            draft saved


            draft discarded



















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53185346%2fjax-rx-blocked-by-cors-policy-method-patch-is-not-allowed-by-access-control-a%23new-answer', 'question_page');
            }
            );

            Post as a guest




















































































            這個網誌中的熱門文章

            Post-Redirect-Get with Spring WebFlux and Thymeleaf

            Xamarin.form Move up view when keyboard appear

            JBPM : POST request for execute process go wrong