I'm guessing that this bit in your post was just by way of example:

print "Do you want to process the stream?";
my $ans = <STDIN>;
[download]

I mean, you wouldn't really need that sort of prompt in a real script: if the person didn't want to process the stream, they wouldn't run the program in the first place, so why ask this kind of question at all? I could imagine many cases where the user needs to provide some kind of decision about how the stream should be processed, and maybe sometimes the user needs some sort of report about the stream before making the decision.

As a rule, stream-based processes handle user input by means of command-line options or flags (e.g. "-q" to suppress warnings or progress reports, "-f" to continue processing despite warnings, "-r" to randomize the output, or whatever...) This is perfectly sensible in the typical case where the user is able to decide, before starting the process, what sort of option they want to use on the given run. If the user needs some info about the stream before making the decision, this might require a separate run, using the script in "probe" or "no_op" mode (or running a separate reporting script on the stream) to get the needed information before doing the processing run with their decision provided on the command line.

On a separate note, you might save some run-time if you change this:

while (<>) {
   $stream .= $_;
}
[download]

to this:

{
   local $/ = undef;
   $stream = <>;  # slurp all the data in one read
}
[download]