Cross domain put call does not work with Access-Control-Allow-Origin

Question

I am facing problem related to cross domain PUT call , i have allowed Access-Control-Allow-Origin from server side put still it doesn't work.

    @PUT
    @Path("/getresponse/{caller}")
    @Produces({MediaType.APPLICATION_JSON})
    public Response getResponseData(@PathParam("caller") String caller ,@QueryParam("ticket")String ticket ,@FormParam("formParam") String data){


        ResponseBuilder resp;
        System.out.println("name of caller is -> "+ caller);
        System.out.println("query param ticket -> "+ ticket);
        System.out.println("form param data->" + data);
        Employee emp = new Employee();
        emp.setAge(23);
        emp.setName("data");
        Gson gson = new Gson();
        String responseJson =  gson.toJson(emp);
        resp=Response.ok(responseJson);//header("Access-Control-Allow-Origin", "*")
        resp.header("Access-Control-Allow-Origin", "*")
        .header("Access-Control-Allow-Methods", "GET, POST, PUT, OPTIONS");

         return resp.build();
    }

whenever i call it from jquery ajax method it says Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource

I have same replica of above service but with POST signature when i call that service it calls service without any problem Post service code is

    @POST
    @Path("/getresponses/{caller}")
    @Produces({MediaType.APPLICATION_JSON})
    public Response getResponseData1(@PathParam("caller") String caller ,@QueryParam("ticket")String ticket ,@FormParam("formParam") String data){


        ResponseBuilder resp;
        System.out.println("name of caller is -> "+ caller);
        System.out.println("query param ticket -> "+ ticket);
        System.out.println("form param data->" + data);
        Employee emp = new Employee();
        emp.setAge(23);
        emp.setName("data");
        Gson gson = new Gson();
        String responseJson =  gson.toJson(emp);
        resp=Response.ok(responseJson);//header("Access-Control-Allow-Origin", "*")
        resp.header("Access-Control-Allow-Origin", "*")
        .header("Access-Control-Allow-Methods", "GET, POST");
        return resp.build();
    }

My client side code is

$(document).ready(function(){
    // for post service
    $('#sendcall').on('click',function(e){
        var dataTosend ="formParam=data to send";
        $.ajax({
              url: 'http://someip:8099/Jqgrid/rest/getdata/getresponses/data?ticket=tick',
              contentType : 'application/x-www-form-urlencoded',
              data :dataTosend,   
              type: 'POST',
              success: function(data){
                alert(data);
              }
            });
    });

    //for PUT service
    $('#sendcall2').on('click',function(e){
        var datatosend ="formParam=data to send";
        $.ajax({
              url: 'http://someip:8099/Jqgrid/rest/getdata/getresponse/aliahsan?ticket=tick',
              contentType : 'application/x-www-form-urlencoded',
              data :datatosend,   
              type: 'PUT',
              crossDomain:true,
              beforeSend: function (xhr) {

                    console.log('header added');
                },
              success: function(data){
                alert(data);
              }
            });
    });
});

Please help me in this regard why PUT is not working with this. Any help will be greatly appreciated

Don't add the CORS headers in the method. [Use a filter](http://stackoverflow.com/a/28067653/2587435) — Paul Samsotha, Dec 21 '15 at 13:38
Why using filter works but not with CORS in the method @peeskillet — Ali, Dec 21 '15 at 18:53
How CORS works is that first there is a preflight request, which is an OPTIONS request (before the actual request), to try and get the CORS headers. So the headers in the methods mean nothing. — Paul Samsotha, Dec 22 '15 at 00:59
@peeskillet can you please tell why there is no preflight request in case of POST but with PUT there is a preflight request ?? — Ali, Dec 22 '15 at 05:10
Generally with application/x-www-form-urlencoded, there is no preflight needed. More commonly is it needed for JSON. So because of the content-type the POST doesn't need to handle preflight. In the PUT, you are forcing the cross domain request with `crossDomain: true`. See [`jQuery.ajax`](http://api.jquery.com/jquery.ajax/). Also to read more about CORS, see [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS) — Paul Samsotha, Dec 22 '15 at 05:15
Actually, looking again at the last document I linked to, i the "Preflight request" section, it seems like it is the PUT method that causes the preflight — Paul Samsotha, Dec 22 '15 at 05:54
@peeskillet put all the summary in answer so that i can accept answer — Ali, Dec 22 '15 at 06:08

score 5 · Accepted Answer · edited May 23 '17 at 10:27

Instead of adding all the CORS headers inside your resource method, use a Jersey filter, as described in this post. The reason for this, is the CORS preflight request, which is defined in HTTP access control (CORS) as:

"preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send.

So the request is an OPTIONS request and it expects back the the "Accept-Xxx" CORS headers to determine what is allowed by the server. So putting the headers in the resource method has no affect as the the request is made with the OPTIONS HTTP method, which you don't have a resource method for. This generally leads to a 405 Method Not Allowed error sent to the client.

When you add the headers in the filter, every request goes through this filter, even the OPTIONS request, so the preflight gets the according headers.

As for the PUT, also described in the above linked document (continuing from the above quote)

Cross-site requests are preflighted like this since they may have implications to user data. In particular, a request is preflighted if:

It uses methods other than GET, HEAD or POST. Also, if POST is used to send request data with a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain, e.g. if the POST request sends an XML payload to the server using application/xml or text/xml, then the request is preflighted.

It sets custom headers in the request (e.g. the request uses a header such as X-PINGOTHER)

This is why the POST request doesn't face the same problem.

Cross domain put call does not work with Access-Control-Allow-Origin

1 Answers1

Linked