Lose the dependency on cURL
HTTP/1.0 or HTTP/1.1 aren't such a big deal after all and we don't use most of what cURL provides, yet require users/packagers to install it. The http-parser is already fairly battle-tested and should handle the real world pretty well without additional fix-ups. cURL sends 1.1 requests by default and the 1.0 specification doesn't provide any convenient means for rejecting requests based on their version, so let's follow suit in assuming that the 21 years old standard will work. (Also see better informed notes in #5.)
Just maintain a connection in a very similar manner to the WebSocket backend. Inform about redirects but don't follow them. Inform about "426 Upgrade Required" responses, especially when it refers to WebSocket. Remember to send
Accept-Encoding: or potentially
deflate (when built with zlib, a trivial transformation). Take care to reject unsupported
Transfer-Encodings, even it is prohibited. Advertise them with
http_should_keep_alive() is how we detect a connection that is meant to be closed, though it probably shouldn't matter to us--either the connection is aborted while we are sending/receiving data and it is an error, or it is aborted at some other point and we merely reestablish it once we need to (we might special-case ECONNRESET after detecting that the particular connection has successfully processed at least one request and skip displaying an error message, regarding it as a regular EOF). Thinking about this, I can see another way how "Expect" could be useful: when we reuse a connection, the server may be on the verge of aborting it and this reduces the possibility of abrupt timeouts, though we actually can't reliably learn whether the request has been processed by means of HTTP alone anyway.
Connection: keep-alive explicitly, see Wikipedia. We might want to switch to a fully asynchronous sending model, rather than the existing precedent of non-blocking reads and blocking writes.
Deleting a branch is permanent. It CANNOT be undone. Continue?