You can clone with
HTTPS or Subversion.
Should Warp determine whether or not to close a connection based on the size of the remaining request body?
Consider the case where the a client wants to send two requests to the server. The first request has a 2MB request body, which the application entirely ignores. Warp currently will flush that request body and then process the next request.
Perhaps instead, Warp should analyze the remaining request body size, notice that it's over a certain threshold (to be determined via benchmarking), and instead close that connection. The theory is that sending that unnecessary 2MB body over the network presents a higher overhead than creating a new connection.
Is there a precedent? Won't clients think that there was an error?
Firstly... how did you see this so quickly? Is there some Github setting to get emails for all organization issues?
I don't know if there's precedent, but I don't think it will cause a problem. We're going to send a complete response to the client before closing the connection, which should let it realize that everything went OK. But it's certainly something we need to check first.
Yes, I receive an e-mail for each and every issue created on my watched repos, and by default I watch all repos from my organizations (I may opt out, though). However, I do not watch all threads by default, so I wouldn't receive a message for your reply if I hadn't replied or explicitly watched this thread first.
The Watch button at the top will change your settings.
Implementing this will end up raising even more questions. For the time being, let's just drop this idea.