... without light userdata and yet it should be efficient.
Also with checkout layer, but I have no nice way of testing that one.

In particular, throw errors when used in weird ways,
instead of the usual "return nil" semantics.
That might be surprising to some lua users.

...when making calls from lua to C modules; use luaJIT FFI instead.
This eliminates some cases of lua_pushlightuserdata().

On many places we've been assuming that there's only a single worker,
but we still often didn't utilize the property well.  To get the pointer
we used various ways, all even untyped:
 - __worker global variable in lua
 - uv_default_loop()->data
 - kr_request::daemon_context

Now we instead simply define a global typed pointer the_worker.

Nitpick: also worker_{init,deinit}() are reordered to correspond
to the order of the fields, etc.

There's no support for the "dns" and "tls" kinds (for now).

Tested briefly:
> modules = { 'http' }
> net.listen('/tmp/kresd-socket', nil, { kind = 'webmgmt' })
$ socat TCP-LISTEN:5555,reuseaddr,fork UNIX-CLIENT:/tmp/kresd-socket
$ xdg-open http://127.0.0.1:5555

http DoH: make answers include access-control-allow-origin: *

See merge request !823

Vladimír Čunát authored 5 years ago and Tomas Krizek committed 5 years ago

Otherwise most browsers won't allow JS from *other* sites to use the
data - one of the two primary use cases for DoH as stated in RFC 8484.

This is yet another logically equivalent change after 270d9964.
Now it's written in a way that expresses the original intention more
clearly and without copy&paste or long lines.

It seems easiest to verify by inspecting the meaning of the code
*separartely* for the two cases, based on condition:
cur_addr_score < KR_NS_TIMEOUT

daemon TCP to upstream: don't send wrong message length

See merge request !816

See the added comments.  Such bugs are tricky, because the old code
would typically work just fine, only if libuv/OS decided to postpone
copying the data (perhaps large load), we would send two bytes from
this address on C stack - their later value (hard to predict what).

Security risks: the two bytes might theoretically contain information
that was more or less private and we just send it to some DNS server
(possibly over unencrypted TCP), but ATM I find it very unlikely that
this bug could be practically exploited.

clarification to docs for net.bufsize()

See merge request !821

modules/ta_update.test: increase test times for CI

See merge request !822