Lose the dependency on cURL #8

Open
opened 2020-10-15 06:05:46 +02:00 by p · 0 comments
Owner

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 gzip/x-gzip and deflate (when built with zlib, a trivial transformation). Take care to reject unsupported Transfer-Encodings, even it is prohibited. Advertise them with TE.

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.

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 `gzip`/`x-gzip` and `deflate` (when built with zlib, a trivial transformation). Take care to reject unsupported `Transfer-Encoding`s, even it is prohibited. Advertise them with `TE`. `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](https://en.wikipedia.org/wiki/HTTP_persistent_connection#HTTP_1.0). We might want to switch to a fully asynchronous sending model, rather than the existing precedent of non-blocking reads and blocking writes.
p self-assigned this 2020-10-15 06:05:46 +02:00
p added this to the v1.3.0 milestone 2020-10-15 06:05:51 +02:00
p added a new dependency 2020-10-15 11:46:59 +02:00
p added a new dependency 2020-10-18 03:42:51 +02:00
Sign in to join this conversation.
No Label
WIP
easy
priority
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: p/json-rpc-shell#8
No description provided.