[Webkit-unassigned] [Bug 89185] New: AssociatedURLLoader should allow trusted clients to read all headers, not just exposed ones

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=89185

           Summary: AssociatedURLLoader should allow trusted clients to
                    read all headers, not just exposed ones
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: fischman at chromium.org
                CC: abarth at webkit.org


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.