mirror of
https://github.com/denoland/deno.git
synced 2024-12-28 10:09:20 -05:00
576d0db372
Deno.serve's fast streaming implementation was not keeping the request
body resource ID alive. We were taking the `Rc<Resource>` from the
resource table during the response, so a hairpin duplex response that
fed back the request body would work.
However, if any JS code attempted to read from the request body (which
requires the resource ID to be valid), the response would fail with a
difficult-to-diagnose "EOF" error.
This was affecting more complex duplex uses of `Deno.fetch` (though as
far as I can tell was unreported).
Simple test:
```ts
const reader = request.body.getReader();
return new Response(
new ReadableStream({
async pull(controller) {
const { done, value } = await reader.read();
if (done) {
controller.close();
} else {
controller.enqueue(value);
}
},
}),
```
And then attempt to use the stream in duplex mode:
```ts
async function testDuplex(
reader: ReadableStreamDefaultReader<Uint8Array>,
writable: WritableStreamDefaultWriter<Uint8Array>,
) {
await writable.write(new Uint8Array([1]));
const chunk1 = await reader.read();
assert(!chunk1.done);
assertEquals(chunk1.value, new Uint8Array([1]));
await writable.write(new Uint8Array([2]));
const chunk2 = await reader.read();
assert(!chunk2.done);
assertEquals(chunk2.value, new Uint8Array([2]));
await writable.close();
const chunk3 = await reader.read();
assert(chunk3.done);
}
```
In older versions of Deno, this would just lock up. I believe after
|
||
|---|---|---|
| .. | ||
| benches | ||
| 00_serve.js | ||
| 01_http.js | ||
| Cargo.toml | ||
| compressible.rs | ||
| http_next.rs | ||
| hyper_util_tokioio.rs | ||
| lib.rs | ||
| network_buffered_stream.rs | ||
| reader_stream.rs | ||
| README.md | ||
| request_body.rs | ||
| request_properties.rs | ||
| response_body.rs | ||
| slab.rs | ||
| websocket_upgrade.rs | ||