Al depurar un problema de CORS que estoy experimentando, he encontrado el siguiente comportamiento. Chrome realiza la siguiente solicitud de verificación previa de OPCIONES (reescrita en CURL por el propio 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'

La respuesta del servidor a esta solicitud es la siguiente:

< 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

siendo el cuerpo de la respuesta 'Solicitud CORS no válida'. Si repito la solicitud eliminando el encabezado 'Método de solicitud de control de acceso' (y solo ese encabezado), las solicitudes de OPTIONS tienen éxito con la siguiente respuesta:

< 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

Sin embargo, el encabezado ofensivo es unEncabezado estándar de especificaciones CORS así que no debería evitar que la solicitud tenga éxito, ¿verdad? ¿Por qué este encabezado está causando tal comportamiento?

¿Y cómo puedo modificar los encabezados de control de acceso enviados por mi servidor para que la solicitud funcione cuando se realiza con Chrome?

Por cierto, estoy usando Chrome 36.0, y el servidor está usando Spring Boot, con los encabezados CORS administrados por Spring.

Cuando Firefox realiza la solicitud (v47.0), el comportamiento es diferente pero con un resultado analógico. Firefox ni siquiera envía la solicitud de verificación previa, envía directamente la solicitud POST, que recibe como respuesta un 403 Prohibido. Sin embargo, si copio la solicitud con la opción 'Copiar como cURL' y la repito desde una ventana de terminal, se realiza correctamente y envía los encabezados CORS correctos en la respuesta.

¿Alguna idea?

Actualizar: Firefox envía la solicitud OPTIONS de verificación previa (como se muestra en el complemento de encabezados HTTP Live), pero Firebug lo enmascara, por lo que el comportamiento en ambos navegadores es exactamente el mismo. En ambos navegadores, el encabezado 'Método de solicitud de control de acceso' es la diferencia que hace que la solicitud falle.