Ao depurar um problema do CORS, encontrei o seguinte comportamento. O Chrome faz a seguinte solicitação de comprovação de OPTIONS (reescrita no CURL pelo próprio Chrome):

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, like 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'

A resposta do servidor para esta solicitação se o seguinte:

< HTTP/1.1 403 Forbidden
< Date: Thu, 21 Jul 2016 14:16:56 GMT
* Server Apache/2.4.7 (Ubuntu) is 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

sendo o corpo da resposta 'Solicitação CORS inválida'. Se eu repetir a solicitação removendo o cabeçalho 'Access-Control-Request-Method' (e somente esse cabeçalho), as solicitações OPTIONS serão bem-sucedidas com a seguinte resposta:

< HTTP/1.1 200 OK
< Date: Thu, 21 Jul 2016 14:21:27 GMT
* Server Apache/2.4.7 (Ubuntu) is 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

No entanto, o cabeçalho ofensivo é umCabeçalho padrão de especificação CORS então não deve impedir que a solicitação seja bem-sucedida, certo? Por que esse cabeçalho está causando esse comportamento?

E como posso ajustar os cabeçalhos de controle de acesso enviados pelo meu servidor para fazer a solicitação funcionar quando feita com o Chrome?

A propósito, estou usando o Chrome 36.0 e o servidor está usando o Spring Boot, com os cabeçalhos do CORS sendo gerenciados pelo Spring.

Quando a solicitação é feita pelo Firefox (v47.0), o comportamento é diferente, mas com um resultado analógico. O Firefox nem envia a solicitação de comprovação, envia diretamente a solicitação POST, que recebe como resposta 403 403 Proibido. No entanto, se eu copiar o pedido com a opção 'Copiar como cURL' e repeti-lo em uma janela de terminal, ele obtém êxito e envia os cabeçalhos CORS corretos na resposta.

Qualquer ideia?

Atualizar: O Firefox envia a solicitação OPTIONS de comprovação (conforme mostrado pelo plug-in Live HTTP headers), mas o Firebug a mascara, de modo que o comportamento nos dois navegadores é exatamente o mesmo. Nos dois navegadores está o cabeçalho 'Access-control-request-method', a diferença que faz com que a solicitação falhe.