takes icon indicating copy to clipboard operation
takes copied to clipboard

Do not allow closing of the live input stream

Open laeubi opened this issue 1 year ago • 7 comments

Currently the raw stream is passed to downstream consumers of RqLive, this has the problem that such consumers can close the stream. In case of a socket, this means the socket itself is closed and no response can be send by takes.

This wraps the original live input stream into one that simply ignores the close request.

laeubi avatar Oct 29 '24 07:10 laeubi

Another option would be to handle it on all different places where such streams are used, but it seems more clean to handle it more like at the roots.

laeubi avatar Oct 29 '24 08:10 laeubi

One problem is that currently RqTemp uses RqLive in a way that relies on close... so one can also handle this in BkBasic

@yegor256 any guidance on this how it is best to be handled? Maybe have (another) wrapper RqNoClose ?!?

laeubi avatar Oct 29 '24 08:10 laeubi

Testcase is currently also missing. Where would be the best place to place such test that fails if no response is given?

laeubi avatar Oct 29 '24 08:10 laeubi

@laeubi who is the consumer of the InputStream that may close it "accidentally"? Can you give an example?

yegor256 avatar Oct 29 '24 08:10 yegor256

In my case I have a POST handler with a TkRegex, there I read the body of the message with a function that closes the passed in stream. While I could workaround this there, it seems consumers should not be able to close the stream/socket as otherwise sending a response is no longer possible.

laeubi avatar Oct 29 '24 09:10 laeubi

@laeubi good point, I believe, you're right. However, I would implement it slightly differently. In the BkBasic I would replace this line:

new RsPrint(this.take.act(req)).print(output);

With this one:

new RsPrint(this.take.act(new RqUncloseable(req))).print(output);

It seems that this is what you suggested earlier as an alternative.

yegor256 avatar Oct 29 '24 09:10 yegor256

@yegor256 it seems the copyright check fails because it explicitly wants something like

Punch line is: "Copyright (c) 2014-2024 Yegor Bugayenko"

is this intentional? Should other names be allowed? I'm not that familiar with MIT license in this regard.

laeubi avatar Jan 01 '25 07:01 laeubi