Access-Control-Allow-Headers
Uso
Cuando un navegador emite una solicitud preflight OPTIONS, la cabecera Access-Control-Request-Headers enumera las cabeceras no incluidas en la lista segura que el cliente pretende enviar. El servidor responde con Access-Control-Allow-Headers para confirmar cuáles de esas cabeceras se aceptan.
Las cabeceras de la lista segura de CORS siempre están permitidas y no necesitan aparecer en esta lista. El conjunto de la lista segura incluye Accept, Accept-Language, Content-Language, Content-Type (con restricciones sobre el tipo de medio y la longitud del valor) y Range (con restricciones sobre el formato). Enumerar explícitamente una cabecera de la lista segura elimina las restricciones adicionales sobre el valor.
Varios nombres de cabecera aparecen como una lista separada por comas.
Lista de nombres de cabecera
Un conjunto de nombres de cabecera separados por comas que el servidor acepta en la solicitud real.
Access-Control-Allow-Headers: Content-Type, Authorization* (comodín)
El asterisco actúa como comodín para las solicitudes sin credenciales y permite cualquier nombre de cabecera.
Access-Control-Allow-Headers: *Nota
En las solicitudes con credenciales, el comodín * se trata como una cadena literal, no como comodín. Cada cabecera permitida debe enumerarse explícitamente cuando hay credenciales presentes. La cabecera Authorization nunca queda cubierta por el comodín y siempre debe indicarse de forma explícita.
Ejemplo
Una solicitud preflight pregunta si se permiten Content-Type y una cabecera personalizada X-Request-ID. El servidor confirma ambas.
Solicitud
OPTIONS /api/data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, X-Request-IDRespuesta
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, X-Request-ID
Access-Control-Max-Age: 86400Un servidor que utiliza el comodín para solicitudes sin credenciales responde con un único carácter.
Access-Control-Allow-Headers: *Diagnóstico
Los fallos de preflight relacionados con las cabeceras de solicitud producen errores en la consola y bloquean la solicitud real.
La consola muestra “Request header field X is not allowed by Access-Control-Allow-Headers in preflight response.”. El servidor no incluyó ese nombre de cabecera en el valor de Access-Control-Allow-Headers. Añada la cabecera que falta a la respuesta de preflight. En nginx: add_header Access-Control-Allow-Headers “Content-Type, Authorization, X-Request-ID”; En Apache: Header set Access-Control-Allow-Headers “Content-Type, Authorization, X-Request-ID”
La respuesta de preflight carece por completo de la cabecera. El servidor atiende la solicitud OPTIONS, pero no incluye Access-Control-Allow-Headers en la respuesta. Muchos frameworks requieren una configuración CORS explícita para las rutas de preflight. Compruebe que el manejador o el middleware de OPTIONS establece esta cabecera junto con Access-Control-Allow-Methods y Access-Control-Allow-Origin.
El comodín * no funciona con solicitudes con credenciales. Cuando Access-Control-Allow-Credentials es true, el comodín se trata como la cadena literal * y no coincide con nada. Enumere explícitamente cada cabecera permitida. La cabecera Authorization nunca queda cubierta por el comodín, ni siquiera en solicitudes sin credenciales, y siempre debe indicarse.
Los nombres de cabecera parecen distinguir mayúsculas y minúsculas en algunos servidores. Según el protocolo, los nombres de cabecera HTTP no distinguen entre mayúsculas y minúsculas, pero algunos frameworks de servidor realizan una comparación de cadenas sensible a mayúsculas al comprobar la lista de permitidos. Una solicitud que envía content-type puede fallar si el servidor solo enumera Content-Type. Haga coincidir el uso de mayúsculas que envía el cliente o normalice ambos lados a minúsculas en la configuración de CORS.
Enviar Content-Type: application/json desencadena un preflight inesperado. La cabecera Content-Type solo está en la lista segura para los valores application/x-www-form-urlencoded, multipart/form-data y text/plain. El valor application/json queda fuera de la lista segura y fuerza un preflight. Añada Content-Type a la lista de Access-Control-Allow-Headers. Para confirmar que se activa el preflight, abra la pestaña Network de DevTools y filtre por método para detectar la solicitud OPTIONS que precede a la solicitud real.