This is high-priority because it will be hard to change proto after BackgroundFetch ships.

rayankans on https://chromium-review.googlesource.com/c/chromium/src/+/1057271 says:
"It would be useful to be able to store and reinitialize full fetch
request data (not just the url). As a specific example, this is needed
for background fetch to resume a fetch after a browser restart."

I guess the cache storage one doesn't have the the full data?

Thanks for raising this.
The context is here:
https://github.com/web-platform-tests/wpt/pull/10192#issuecomment-383880561

According to that, Cache API also needs full fields, but we don't have it.

wanderview@ said: 

  The Cache API spec just stores the Request in a conceptual map, so it implies it should persist.[1]

I agree with that opinion.

1: https://github.com/web-platform-tests/wpt/pull/10192#issuecomment-383932230

The structure is quite lossy right now as many of the fields are missing, and the persistent Request w/ full options ==> Response mapping is important to us.

If we're going to store all fields, what does that imply for request bodies?

> If we're going to store all fields, what does that imply for request bodies?

FWIW, the Cache API spec only supports storing GET and HEAD requests right now.  Neither of those request methods are allowed to have upload bodies.

[blink worker triage] I'm not sure this qualifies as P1 as it's not needed for a target milestone. Since the concern was about Background Fetch shipping, it can just be a blocking bug on Background Fetch.

Rayan, please can you help drive this forward?

The situation hasn't change. If you are going to close this as WONTFIX, please explain the reason.

Thanks yhirano@

Marking as WontFix (obsolete) since:
- ServiceWorkerFetchRequest will be eventually replaced with FetchAPIRequest.
- Cache Storage backend will use a different indexing method to support vary headers.