Redemption of a large batch of ZKAPs tends to fail for slower clients

The timeout functionality built in to Warp (the network/HTTP library) looks unfavorably on the time it can take to transfer the full response body to the client when there are many signatures and the client isn't extremely fast. The default Warp configuration always times out connections while a remote PaymentServer is trying to transfer 384000 signatures to my local laptop. My internet connection isn't the greatest and the timeout happens at around the 4m30s mark (not precisely, that's just the closest round number).

I hypothesis this is because progress is respected during the blinded token upload (which takes perhaps a couple minutes) and the timeout is suspended during redemption itself (application code which takes perhaps a couple minutes) but then progress is not respected during signature download. While the 10-20 MiB of signatures are being downloaded, the 30 (or maybe 60) second timeout eventually elapses and the connection is closed even though the transfer is still in progress.

I'm tempted to say that this is a Warp misbehavior but it's also hard to describe precisely what is wrong about it. The purpose of the timeout is to protect against an easy DoS attack where clients cause servers to commit significant resources without doing so themselves. This could certainly describe the situation here.