Today AssociatedURLLoader::ClientAdapter::didReceiveResponse() copies the response for the benefit of its client, stripping out blocked headers. This makes it impossible for any code, trusted or not, to inspect such headers. An example problem this raises: chromium's media loading code specifies Range: in its request header, so it requests [origin, accept-encoding, referer, range] in the CORS pre-flight request (Access-Control-Request-Headers). When it receives a 206 response, it wants to use the Content-Range, Content-Length, and Accept-Ranges headers, but it can't do so because these are not "simple headers" (in CORS-speak) and are not explicitly included in Access-Control-Expose-Headers because the server doesn't necessarily know the client requires them, so AssociatedURLLoader::ClientAdapter::didReceiveResponse() strips them out of the response copy handed to BufferedResourceLoader. Instead, there should be an API for trusted code to side-step this header-stripping.
Created attachment 147805 [details] Proposed patch
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Created attachment 147806 [details] Proposed patch
Ignore the first patch - it doesn't build.
Adam, this new WebURLLoaderOption field completely turns off response header filtering. Therefore this would expose "set-cookie" headers to the client. I'm assuming this is OK since it's trusted.
Comment on attachment 147806 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=147806&action=review Interesting approach. I was expecting you to add another function for grabbing the headers, but I see why you've taken this approach. > Source/WebKit/chromium/public/WebURLLoaderOptions.h:57 > + bool allowResponseHeaders; // If policy is to use access control, whether to allow non-simple response headers. I wonder if we should name this something like exposeAllResponseHeaders to mimic the name of Access-Control-Expose-Headers ?
Created attachment 147859 [details] Proposed Patch 'exposeAllResponseHeaders' is a much better name. Thanks.
Comment on attachment 147859 [details] Proposed Patch Clearing flags on attachment: 147859 Committed r120490: <http://trac.webkit.org/changeset/120490>
All reviewed patches have been landed. Closing bug.