Lose the dependency on cURL #8
Labels
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Blocks
Depends on
#9 Publish a static build
p/json-rpc-shell
#5 json-rpc-test-server: add a pure HTTP listener
p/json-rpc-shell
Reference: p/json-rpc-shell#8
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 potentiallygzip
/x-gzip
anddeflate
(when built with zlib, a trivial transformation). Take care to reject unsupportedTransfer-Encoding
s, even it is prohibited. Advertise them withTE
.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.Send
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.