Re: [whatwg/fetch] Fail request when its streaming body is used in ServiceWorker (#1144)

@jakearchibald commented on this pull request.



> @@ -3834,9 +3834,32 @@ optional <i>CORS-preflight flag</i>, run these steps:
   <p>If <var>request</var>'s <a>service-workers mode</a> is "<code>all</code>", then:
 
   <ol>
+   <li><p>Assert: <var>request</var> 's <a for=request>body</a> is either null or a
+   <a for=/>body</a>.
+
+   <li>
+    <p>Let <var>savedBody</var> be a copy of <var>request</var>'s <a for=request>body</a>.

Just to check I'm understanding the above correctly:

1. The _originalRequest_ is sent to the service worker, and `event.request` represents that _originalRequest_.
2. `event.request.clone()` creates two new bodies by teeing, one for `event.request`, and one for the new cloned request.
3. The body associated with _originalRequest_ is now locked, due to the teeing process.

If the above is wrong, it's probably best to ignore the rest of this 😄 

---

We could clone the request (including teeing the body) before sending it to the service worker, giving us _originalRequest_ and _originalRequestForServiceWorker_.

1. _originalRequestForServiceWorker_ is sent to the service worker as `event.request`.
2. If `event.respondWith` is called, then _originalRequest_'s body can be closed. Otherwise, _originalRequestForServiceWorker_'s body can be closed (unless it's already locked).

I think this would allow cloning without increasing memory usage much. It would also mean you can call `event.request.text()` without calling `event.respondWith`, without creating a network error. I don't know if that's a feature or a bug. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1144#discussion_r573692785