while debugging cors issue experiencing i've found following behaviour. chrome makes following options preflight request (rewritten in curl chrome itself):
curl -v 'https://www.example.com/api/v1/users' -x options -h 'access-control-request-method: post' -h 'origin: http://example.com' -h 'accept-encoding: gzip,deflate,sdch' -h 'accept-language: es-es,es;q=0.8,en;q=0.6' -h 'user-agent: mozilla/5.0 (x11; linux x86_64) applewebkit/537.36 (khtml, gecko) chrome/36.0.1985.125 safari/537.36' -h 'accept: */*' -h 'referer: http://example.com/users/new' -h 'connection: keep-alive' -h 'access-control-request-headers: accept, x-api-key, content-type' the response server request if following:
< http/1.1 403 forbidden < date: thu, 21 jul 2016 14:16:56 gmt * server apache/2.4.7 (ubuntu) not blacklisted < server: apache/2.4.7 (ubuntu) < 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 < strict-transport-security: max-age=31536000 ; includesubdomains < x-frame-options: sameorigin < allow: get, head, post, put, delete, trace, options, patch < content-length: 20 < keep-alive: timeout=5, max=100 < connection: keep-alive being body of response 'invalid cors request'. if repeat request removing header 'access-control-request-method' (and header) options requests succeeds following reponse:
< http/1.1 200 ok < date: thu, 21 jul 2016 14:21:27 gmt * server apache/2.4.7 (ubuntu) not blacklisted < server: apache/2.4.7 (ubuntu) < 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 < strict-transport-security: max-age=31536000 ; includesubdomains < x-frame-options: sameorigin < access-control-allow-headers: origin, content-type, accept, x-requested-with, x-api-key < access-control-max-age: 60 < access-control-allow-methods: get, post, put, delete, options < access-control-allow-origin: * < allow: get, head, post, put, delete, trace, options, patch < content-length: 0 < keep-alive: timeout=5, max=100 < connection: keep-alive however, offending header cors spec standard header should not prevent request succeeding, right? why header causing such behaviour?
and how can tweak access control headers sent server make request work when made chrome?
by way, using chrome 36.0, , server using spring boot, cors headers being managed spring.
when request made firefox (v47.0) behaviour different analogue result. firefox not send preflight request, directly sends post request, receives response 403 forbidden. however, if copy request 'copy curl' option, , repeat terminal window, succeeds , sends correct cors headers in response.
any idea?
update: firefox send preflight options request (as shown live http headers plugin), firebug masks it, behaviour in both browsers same. in both browsers 'access-control-request-method' header difference makes request fail.
after lot of struggling, found problem. configured request mapping in spring handle options traffic, this:
@requestmapping(value= "/api/**", method=requestmethod.options) public void corsheaders(httpservletresponse response) { response.addheader("access-control-allow-origin", "*"); response.addheader("access-control-allow-methods", "get, post, put, delete, options"); response.addheader("access-control-allow-headers", "origin, content-type, accept, x-requested-with"); response.addheader("access-control-max-age", "3600"); } i did not know default spring uses default cors processor, , seems interfering request mapping. deleting request mapping , adding @crossorigin annotation appropriate request mappings solved problem.
Comments
Post a Comment