Bug 247942 – Evaluate what happens to application specific HTTP headers in case of 301 cached redirections

• Status: NEW
• Component: WebCore Misc.

[youenn fablet]

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.

[youenn fablet]

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

[Radar WebKit Bug Importer]

<rdar://problem/102362992>

[youenn fablet]

Pull request: https://github.com/WebKit/WebKit/pull/6549

[Anne van Kesteren]

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.

[youenn fablet]

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.