[whatwg/fetch] Question about stream handling around fetch requests with integrity metadata (Issue #1754)

Hello - we've slowly been making the [Ladybird browser](https://ladybird.dev/) use the streams spec for fetch, and ran into a couple issues with fetch requests that have integrity metadata.

In [main fetch](https://fetch.spec.whatwg.org/#concept-main-fetch) step 22, we have (abbreviated here):
```
22. If request’s integrity metadata is not the empty string, then:
    3. Let processBody given bytes be these steps:
         3. Run fetch response handover given fetchParams and response.
    4. Fully read response’s body given processBody and processBodyError.
```

Where, in [fetch response handover](https://fetch.spec.whatwg.org/#fetch-finale), we create a transform stream to pipe the request's body through:
```
6. If internalResponse’s body is null, then run processResponseEndOfBody.
7. Otherwise:
    1. Let transformStream be a new TransformStream.
    2. Let identityTransformAlgorithm be an algorithm which, given chunk, enqueues chunk in transformStream.
    3. Set up transformStream with transformAlgorithm set to identityTransformAlgorithm and flushAlgorithm set to processResponseEndOfBody.
    4. Set internalResponse’s body’s stream to the result of internalResponse’s body’s stream piped through transformStream.
```

The first issue we hit is that when we [fully read the response body](https://fetch.spec.whatwg.org/#body-fully-read), we acquire a reader for the body's stream. This locks the stream. I might be missing something, but I don't see anywhere that releases this acquired reader (and thus unlocks the stream). This causes an assertion failure later when the fetch response handover is run - the first step of [piping through](https://streams.spec.whatwg.org/#readablestream-pipe-through) states:
```
1. Assert: ! IsReadableStreamLocked(readable) is false.
```
So should the steps for fully reading the body include [releasing the acquired reader](https://streams.spec.whatwg.org/#abstract-opdef-readablestreamdefaultreaderrelease) in its success / error steps?

The second issue we hit is that the body's stream is actually closed by the time we get to piping through to the transform stream. This happens after the [body is extracted](https://fetch.spec.whatwg.org/#concept-bodyinit-extract):
```
12. If action is non-null, then run these steps in parallel:
    1. Run action.
    Whenever one or more bytes are available and stream is not errored, enqueue the result of creating a Uint8Array from the available bytes into stream.
    When running action is done, close stream.
```

The stream isn't closed right away there, because we just enqueued some data - rather, it gets marked with as "close requested". When we fully read the response body from main-fetch, we receive the queued data, and then the stream is actually closed.

So then when we enter the transform stream steps, the response body's stream is closed, which prevents the pipe-through operation from actually doing anything (as far as I can tell), because there's no queued data (it was taken by fully-read) and no way to pull more data.



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

Message ID: <whatwg/fetch/issues/1754@github.com>