Keywords: CORS | Access-Control-Allow-Headers | Wildcard | Browser Compatibility | Cross-Origin Requests
Abstract: This article discusses the common issue where the wildcard (*) in the Access-Control-Allow-Headers header is ignored by older browsers, leading to CORS failures. It explains the historical context, browser support, and provides practical solutions including dynamic header echoing and alternative approaches.
Introduction to Cross-Origin Resource Sharing (CORS)
Cross-Origin Resource Sharing (CORS) is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served. However, configuring CORS headers correctly can be challenging, especially with the use of wildcards in headers like Access-Control-Allow-Headers.
The Wildcard Issue in Access-Control-Allow-Headers
In the provided scenario, a developer encountered an error where Chrome rejected a CORS request despite setting Access-Control-Allow-Headers: * in the response. The error message indicated that the Content-Type header was not allowed, suggesting that the wildcard was being ignored.
Historical Context and Browser Support
According to the CORS specification, support for wildcards in Access-Control-Allow-Headers was added to the living standard only in May 2016. Prior to that, browsers required an exact match for allowed headers. This means that older browsers, such as Chrome 22 used in the example, do not support the wildcard and will treat it as invalid, leading to CORS failures.
Practical Solution: Dynamic Header Echoing
A robust solution is to dynamically read the Access-Control-Request-Headers from the preflight request and echo it back in the Access-Control-Allow-Headers response header. This ensures compatibility across all browsers.
Here is a revised Python code example based on the original server implementation:
self.send_response(200)
self.send_header('Allow', 'GET, POST, OPTIONS')
self.send_header('Access-Control-Allow-Origin', '*')
# Read the requested headers and echo them back
request_headers = self.headers.get('Access-Control-Request-Headers', '')
self.send_header('Access-Control-Allow-Headers', request_headers)
self.send_header('Content-Length', '0')
self.end_headers()This code snippet retrieves the value of Access-Control-Request-Headers from the incoming request and sets it as the value for Access-Control-Allow-Headers, ensuring an exact match.
Alternative Approach: Listing All Headers
As a supplementary method, some configurations, such as in .htaccess files, list all possible headers explicitly to avoid wildcard issues. However, this approach can be cumbersome and may not be future-proof, as new headers can be introduced.
For instance, in an Apache server configuration, one might set:
Header set Access-Control-Allow-Headers "Accept, Content-Type, Origin, ..."This method is less recommended due to maintenance overhead but can be used in static environments.
Conclusion and Best Practices
To ensure reliable CORS implementation, avoid using wildcards in Access-Control-Allow-Headers for cross-browser compatibility. Instead, adopt dynamic echoing of requested headers or explicitly list necessary headers. Always test with target browsers and keep abreast of specification updates to leverage newer features appropriately.