yutakahirano/fetch-with-streams

.bodyUsed vs. .locked

yutakahirano opened this issue · 4 comments

yutakahirano commented

The current draft states the following.

The bodyUsed attribute's getter must return if the read end of the body is locked.

That reflects discussion at w3c/ServiceWorker#452.

However, that may be problematic because the lock will be unlocked when the stream is closed or errored, if "the lock" behaves as same as an ExclusiveStreamReader defined at https://streams.spec.whatwg.org/#reader-class.
That means when an error happens in processing text() .bodyUsed will become false.

@tyoshino @domenic What do you think?

yutakahirano commented

One solution is to state that once the lock is acquired by text(), arrayBuffer(), formData, blob() and json(), it will never released even when the stream is closed or errored. Is it natural, and reasonable?

yutakahirano commented

Possible solutions...

  1. Make the lock acquired by those methods unreleasable (i.e. #13 (comment)).
  2. .bodyUsed is no longer isLocked.
  3. Reconsider the ExclusiveStreamReader spec again.
  4. Make .bodyUsed accord with isLocked. This changes the meaning of .bodyUsed in the fetch spec.

I don't like the second solution. Unifying consume body algorithm with other algorithms such as pipeTo is natural and reasonable. Having inconsistent multiple algorithms will confuse developers.

domenic commented

Yes, this is related to my question in w3c/ServiceWorker#452 (comment).

In short, I see two potential solutions:

  • Remove .bodyUsed and just expose .body.isLocked
  • Change the meaning of bodyUsed to not be related to locks but instead give you some idea whether the data in the stream has been read, as in w3c/ServiceWorker#452 (comment)
yutakahirano commented

Thank you. I should have posted there. I close this issue and will post there.