- From: Ben Kelly <notifications@github.com>
- Date: Tue, 20 Jan 2015 05:44:23 -0800
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <slightlyoff/ServiceWorker/issues/452/70654675@github.com>
@yutakahirano Just to clarify one thing: > - The current .bodyUsed specified at https://fetch.spec.whatwg.org/ represents whether some functions such as text() and json() are called. For example, res.text().then(() => res.text()) will be rejected, because .bodyUsed is turned into true at the first text() call and it will never become false. Note that .bodyUsed becomes true even when no data is read - Think about the case when we call text() on a response that has an empty body. > - A stream can be locked. The lock will be released when explicitly indicated, the stream gets closed or the stream gets errored. text() acquires a lock, but it releases the lock when the stream is closed or errored. > - There is another concept: whether body data is read. Let me call it .bodyConsumed for now. It becomes true when some data is read via ReadableStream.prototype.read. res.text() will turn this flag into true when the data is actually read (not when the function is called). Note that res.text() on a response with an empty body doesn't make this flag true. The .bodyUsed flag is also set when the UA drains the body. For example, Cache.put() will drain the bodies for both the Request and Response objects. Cache.put(req, res) will result in both req.bodyUsed and res.bodyUsed being set to true. Setting these used flags occurs at the beginning of the put(), before any data is read yet. I believe we did this so that the UA can read the data on another thread without worrying about racing with content for the body data. See steps 3.2 and 5.2. https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#cache-put Just wanted to note that as it didn't seem directly covered by your other cases. --- Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/issues/452#issuecomment-70654675
Received on Tuesday, 20 January 2015 13:44:50 UTC