This should speed up repeated requests to the same site by keeping their
connections around and sending more requests on them.
Sending multiple requests at the same time is not supported, instead a
request started while another to the same authority is in progress would
open a new one and the first one to complete would go back in the pool.
This could be investigated in the future.
Some http servers limit the number of requests per connection and this
is not tested and could cause one request to fail, but hopefully it will
close the connection and prevent it from being reused.
Previously, if surrounding code was not configuring the TLS context
used default in net.http, it would not validate certificates at all.
This is not a security issue with prosody, because prosody updates the
context with `verify = "peer"` as well as paths to CA certificates in
util.startup.init_http_client.
Nevertheless... Let's not leave this pitfall out there in the open.
When opportunistic writes are enabled this reduces the number of
syscalls and TCP packets sent on the wire.
Experiments with TCP Fast Open made this even more obvious.
That table trick probably wasn't as efficient. Lua generates bytecode
for a table with zero array slots and space for two entries in the hash
part, plus code to set [2] and [4]. I didn't verify but I suspect it
would have had to resize the table when setting [1] and [3], although
probably only once. Concatenating the strings directly in Lua is easier
to read and involves no extra table or function call.
Promise mode is not (widely?) used, changing this now while we can, as it
improves usability of the API.
The request is now available as response.request, if needed.
Partial backports of the following commits from trunk:
6c804b6b2ca2 net.http: Pass server name along for SNI (fixes#1408)
75d2874502c3 net.server_select: SNI support (#409)
9a905888b96c net.server_event: Add SNI support (#409)
adc0672b700e net.server_epoll: Add support for SNI (#409)
d4390c427a66 net.server: Handle server name (SNI) as extra argument
This is a new API that should be used in preference to http.destroy_request()
when possible, as it ensures the callback is always called (with an error of
course).
APIs that have edge-cases where they don't call callbacks have, from experience,
shown to be difficult to work with and often lead to unintentional leaks when
the callback was expected to free up certain resources.
Commit e3b9dc9dd940 changed the parameter order in 2013, but did not update the names of the parameters in the callback function. Due to this inconsistency, 12df41a5a4b1 accidentally reversed the order when fixing the variable names without fixing where they are used.
Additionally the documentation was incorrect (since 2013), and this has also now been fixed.
