Support for Access-Control-Expose-Headers in the CORS options #738
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added options to CORS to include custom Access-Control-Expose-Headers. It's using the same mechanisms as headers and methods options (a main one with default, in this case to 'WWW-Authenticate, Server-Authorization', and an additional one to add instead of override).
These headers are necessary when making a CORS request to force the getReponseHeader() method of the XmlHttpRequest2 object:
"Access-Control-Expose-Headers (optional) - The XmlHttpRequest2 object has a getResponseHeader() method that returns the value of a particular response header. During a CORS request, the getResponseHeader() method can only access simple response headers. Simple response headers are defined as follows:
If you want clients to be able to access other headers, you have to use the Access-Control-Expose-Headers header. The value of this header is a comma-delimited list of response headers you want to expose to the client." (http://www.html5rocks.com/en/tutorials/cors/#toc-handling-a-simple-request)
The real testing of this feature is hard because it depends on an implementation of XmlHttpRequest2 to make sure that the headers which are specified are truly exposed because this "blindness" is only due to XmlHttpRequest2. Still, I added a test for existence of the default exposed headers where I found the test for existence of the default headers.
The choice of the default exposed headers was made to match what's needed by Hawk.