http - Preflight request not being handled by apache (CORS) -

general:

request url:x/site.php request method:options status code:302 found remote address:x.x.x.x:80 

response headers:

view source access-control-allow-headers:content-type access-control-allow-origin:* access-control-max-age:300 cache-control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0 content-length:0 content-type:text/html; charset=utf-8 date:thu, 02 mar 2017 14:27:21 gmt expires:thu, 19 nov 1981 08:52:00 gmt location:y pragma:no-cache server:apache/2.4.25 (ubuntu) 

request headers:

view source accept:*/* accept-encoding:gzip, deflate, sdch accept-language:en-us,en;q=0.8 access-control-request-headers:authorization access-control-request-method:post cache-control:no-cache connection:keep-alive dnt:1 host:x origin:http://127.0.0.1:3000 pragma:no-cache referer:http://127.0.0.1:3000/ user-agent:mozilla/5.0 (x11; linux x86_64) applewebkit/537.36 (khtml, gecko) chrome/54.0.2840.90 safari/537.36 

apache virtualhost config looks so:

    <ifmodule mod_headers.c>            header set access-control-allow-origin "http://127.0.0.1:3000"            header set access-control-allow-origin "http://127.0.0.1"            header set access-control-max-age "300"            header set access-control-allow-credentials "true"            header set access-control-allow-headers "origin, x-requested-with, content-type, accept"            header set access-control-allow-methods "post, get, put, delete, patch, options"     </ifmodule> 

the preflight request skipping apache config , hitting webapp directly, redirect (hence 302 , location: y).

i don't know why preflight request not being handled apache?

the 2 main things need change/add are:

• use header set instead of header set
• use mod_rewrite handle options sending 200 ok headers

so enable request in question work, here’s minimal(ish) config snippet:

header set access-control-allow-origin "*" header set access-control-allow-headers "authorization" header set access-control-allow-methods "get, options" header set access-control-expose-headers "content-security-policy, location" header set access-control-max-age "600"  rewriteengine on rewritecond %{request_method} options rewriterule ^(.*)$ $1 [r=200,l] 

longer explanation @ https://benjaminhorn.io/code/setting-cors-cross-origin-resource-sharing-on-apache-with-correct-response-headers-allowing-everything-through/

some general notes on values set various access-control- response headers:

• access-control-allow-headers: must set include header names request sends except    cors-safelisted header names or so-called “forbidden” header names (names of headers set browser can’t set in javascript); the spec alternatively allows * wildcard value—so can try someday, no browser supports yet: chrome bug, firefox bug, safari bug

• access-control-allow-methods: the spec alternatively allows * wildcard—but again, access-control-allow-headers: *, no browsers support yet

• access-control-expose-headers: must set include response headers client code needs read beyond cache-control,content-language,content-type, expires, last-modified , pragma—which exposed default (a lot of people forget set , end baffled why can’t read value of particular response header); again the spec alternatively allows * wildcard here, no browsers support yet

• access-control-max-age: chrome has upper limit of 600 (10 minutes) hardcoded, there’s no point in setting higher value (firefox may respect it, chrome throttle down 10 minutes if set higher, , safari limits 5 minutes)

so then, particular request shown in question, here specific notes:

• your request has access-control-request-headers:authorization in apache config, add authorization in access-control-allow-headers response header too.

• origin “forbidden” header name set browser, , accept cors-safelisted header name, don’t need include them in access-control-allow-headers

• your request sends no content-type, isn’t needed in access-control-allow-headers in response (and never needed get requests , otherwise needed if type other application/x-www-form-urlencoded, text/plain, or multipart/form-data)

• for access-control-allow-methods, request seems get, unless plan make post/put/delete/patch requests, no point in explicitly including them