Evaluate what happens to application specific HTTP headers in case of 301 cached redirections. We should probably use the request application specific headers, and not the cached headers.
See https://bugs.webkit.org/show_bug.cgi?id=247418. I wonder whether we should actually store redirect request in the HTTP cache. Maybe we should just store the location URL, and then recompute dynamically the redirect request from the new request and the location URL. This would allow preserving the new request headers
<rdar://problem/102362992>
Pull request: https://github.com/WebKit/WebKit/pull/6549
As far as I know per HTTP the idea is that the response is cached, not the request. Why are we storing the request? As for what headers to preserve from the request: Fetch preserves them all, though it was recently tweaked slightly to drop a number of headers when the request method changed. https://github.com/whatwg/fetch/issues/944 is still open to drop the Authorization header when another origin is reached. I guess pushing for that now that there's at least one implementation and no known compatibility fallout is a good idea. I can try to make time for that.
CFNetwork provided the redirected request, that might explain the current approach (use it and store it), but it is not always aligned with what we want. We have ResourceRequest::redirectedRequest which is used to generate the redirected request in case of service worker redirection. We could move towards using this for all ports.