Streams getting closed when doing a http request

[unglaublicherdude]

I dunno if I am correct here and if I already found the correct issue corresponding to what confuses me when using react http.

I made a PR for one of our Projects where I stumbled over a behaviour that I put in a test here.

So what I was confused about was, that even when having 2 different instances of the Browser (yeah I know they share one EventLoop) streams will be affected by both. In my example I do an streaming-http request with Browser1 and get the stream for the response and then one with Browser2 and get the stream for the response. What happens now, is that the second http-request done in Browser2 closes the response-stream from the first http-request in Browser1.

Is there some way to prevent this behaviour that is not just pausing and resuming the response-stream? We provide a library for our customers and would have to make sure, they do this the "correct" way then.

[SimonFrings]

Hey @unglaublicherdude, thanks for bringing this up 👍

[...] the stream from request 1 is closed without me doing anything with it.

That is actually the correct behavior here. Breaking down your example from reactphp/http#533, you start by sending out a request and waiting for the streaming response to come in. Once this happens, you'll start receiving data until all data has been received. Checking if the stream is readable will be true in this case.

Then you're starting to send out a second HTTP request and wait for the next streaming response to arrive. This takes some time and the first request is already finished, so as long as we don't take control of the first stream, it will be closed as there's nothing more to do here. You can also listen to any events on this stream to see what's going on behind the scenes, see https://github.com/reactphp/stream?tab=readme-ov-file#readablestreaminterface for more details.

Is there any way we can prevent that besides just doing a pause() and resume()? [...]

Using pause() and resume() should work in this case. This also opens up the question if you really want to use a streaming approach here, but I can't really recommend much without knowing the use case and what you're trying to achieve.

If you're looking for even more help with this, we can also schedule a call and take a closer look at this together. We helped others through consulting with similar questions in the past, so if this is something you're interested in, you can visit https://clue.engineering/#appointment.

[unglaublicherdude]

Hi,

I tried pausing it is actually the last commit in the example I made. It does not seem to work. The stream is still consumed when doing the second http-reuqest. Maybe this is special for the ReadableBodyStream?

I have to use streaming, because the SDK I work on is basically just tunneling the files trough. The files come from anywhere and are put to a specific API to get some information about the file (verdict, file-type, mime-type), so I want to prevent buffering in the SDK because it doesn't need the files content.

[unglaublicherdude]

What I was looking for, was stream handling like this. So basically streams not getting touched before something is actually reading them.