(Includes fixes from Yichen Gu)
Currently the incoming ebuf is always replaced to point to either a whole
buflist segment, or up to the (pt_serv_buf - LWS_PRE) length in the pt_serv_buf.
This is called on path for handling http read... some user code reasonably wants to
restrict the read size to what it can handle.
Change the other lws_buflist_aware_read() callers to zero ebuf before calling, and for
those have it keep the current behaviour; but if non-NULL ebuf.token on incoming, as
in http read path case, restrict both reported len of buflist content and the read length
to the incoming ebuf.len so the user code can control what it will get at one time.
Additionally muxed protocol wsi have no choice but to read what was sent to them
since it's HOL-blocking for other streams and its own WINDOW_UPDATEs. So add an
internal param to lws_buflist_aware_read() forcing read even if buflist content
is available.
This provides support to build lws using the linkit 7697 public SDK
from here https://docs.labs.mediatek.com/resource/mt7687-mt7697/en/downloads
This toolchain has some challenges, its int32_t / uint32_t are long,
so assumptions about format strings for those being %u / %d / %x all
break. This fixes all the cases for the features enabled by the
default cmake settings.
Freertos + lwip doesn't support pipe2() or pipe()... implement a "pipe"
based on two UDP sockets, one listening on 127.0.0.1:54321 and the other
doing a sendto() there of a single byte to interrupt the event loop wait.
Re-use the arrangements for actual pipe fds and pipe role to deliver
lws_cancel_service() functionality using this.
There are some minor public api type improvements rather than cast everywhere
inside lws and user code to work around them... these changed from int to
size_t
- lws_buflist_use_segment() return
- lws_tokenize_t .len and .token_len
- lws_tokenize_cstr() length
- lws_get_peer_simple() namelen
- lws_get_peer_simple_fd() namelen, int fd -> lws_sockfd_type fd
- lws_write_numeric_address() len
- lws_sa46_write_numeric_address() len
These changes are typically a NOP for user code
In the case code is composed into a single process, but it isn't monolithic in the
sense it's made up of modular "applications" that are written separate projects,
provide a way for the "applications" to request a callback from the lws event loop
thread context safely.
From the callback the applications can set up their operations on the lws event
loop and drop their own thread.
Since it requires system-specific locking to be threadsafe, provide a non-threadsafe
helper and then indirect the actual usage through a user-defined lws_system ops
function pointer that wraps the unsafe api with the system locking to make it safe.
This changes the approach of tx credit management to set the
initial stream tx credit window to zero. This is the only way
with RFC7540 to gain the ability to selectively precisely rx
flow control incoming streams.
At the time the headers are sent, a WINDOW_UPDATE is sent with
the initial tx credit towards us for that specific stream. By
default, this acts as before with a 256KB window added for both
the stream and the nwsi, and additional window management sent
as stuff is received.
It's now also possible to set a member in the client info
struct and a new option LCCSCF_H2_MANUAL_RXFLOW to precisely
manage both the initial tx credit for a specific stream and
the ongoing rate limit by meting out further tx credit
manually.
Add another minimal example http-client-h2-rxflow demonstrating how
to force a connection's peer's initial budget to transmit to us
and control it during the connection lifetime to restrict the amount
of incoming data we have to buffer.
This should be a NOP for h2 support and only affects internal
apis. But it lets us reuse the working and reliable h2 mux
arrangements directly in other protocols later, and share code
so building for h2 + new protocols can take advantage of common
mux child handling struct and code.
Break out common mux handling struct into its own type.
Convert all uses of members that used to be in wsi->h2 to wsi->mux
Audit all references to the members and break out generic helpers
for anything that is useful for other mux-capable protocols to
reuse wsi->mux related features.
Saw this on travis selftests during context destroy
==18895== Invalid read of size 8
==18895== at 0x415909: __lws_vhost_destroy2 (vhost.c:1063)
==18895== by 0x40E65B: lws_context_destroy2 (context.c:929)
==18895== by 0x40EBE5: lws_context_destroy (context.c:1128)
==18895== by 0x40CC41: main (minimal-http-client-post.c:267)
==18895== Address 0x6168688 is 728 bytes inside a block of size 792 free'd
==18895== at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18895== by 0x45B29E: _realloc (alloc.c:120)
==18895== by 0x45B2D6: lws_realloc (alloc.c:130)
==18895== by 0x415ED7: __lws_vhost_destroy2 (vhost.c:1204)
==18895== by 0x419164: lws_vhost_unbind_wsi (wsi.c:82)
==18895== by 0x41236B: __lws_free_wsi (close.c:154)
==18895== by 0x4134CF: __lws_close_free_wsi_final (close.c:650)
==18895== by 0x4133BA: __lws_close_free_wsi (close.c:610)
==18895== by 0x413528: lws_close_free_wsi (close.c:660)
==18895== by 0x4158C7: __lws_vhost_destroy2 (vhost.c:1053)
==18895== by 0x40E65B: lws_context_destroy2 (context.c:929)
==18895== by 0x40EBE5: lws_context_destroy (context.c:1128)
Removing the last wsi from the vhost we started to destroy finalized the
vhost destruction, which is aimed at libuv async close cleanup. But if
we already entered __lws_vhost_destroy2, we will definitely destroy the vhost
ourselves at the end of that function already. So defeat the wsi close
triggering it.
On some platforms, it's possible that logging flow may reset errno. In the case where
we try to log errno on those platforms and afterwards try to query it, we will get a
nasty surprise that the logged errno is destroyed by the time we come to test it.
In the two cases of this in the tree at the moment, sample errno into a temp and
log and test the temp.
Thanks to Sakthi Ramabadran for finding this.
Now the generic lws_system blobs can cover client certs + key, let's
add support for applying one of the blob sets to a specific client
connection (rather than doing it via the vhost).
It looks to semmle like the int size can be bigger than the char loop var.
But the size is the size of the IPv4 or IPv6 address, so it cannot make
a problem.
This teaches http client stuff how to handle 303 redirects... these
can happen after POST where the server side wants you to come back with
a GET to the Location: mentioned.
lws client will follow the redirect and force GET, this works for both
h1 and h2. Client protocol handler has to act differently if it finds
it is connecting for the initial POST or the subsequent GET, it can
find out which by checking a new api lws_http_is_redirected_to_get(wsi)
which returns nonzero if in GET mode.
Minimal example for server form-post has a new --303 switch to enable
this behaviour there and the client post example has additions to
check lws_http_is_redirected_to_get().
Pre-sul, checking for interval to next pending scheduled event was expensive and
iterative, so the service avoided it if the wait was already 0.
With sul though, the internal "check" function also services ripe events and
removes them, and finding the interval to the next one is really cheap.
Rename the "check" function to __lws_sul_service_ripe() to make it clear it's
not just about returning the interval to the next pending one. And call it
regardless of if we already decided we are not going to wait in the poll.
After https://github.com/warmcat/libwebsockets/pull/1745
As it is, if time_t is 32-bit on the platform it might lead to
arithmetic overflow, so force it to lws_usec_t (uint64_t) even
though it works OK here on x86_64.
Add a minimal example aimed at testing the wsi hrtimer stability
consistently across platforms.
Add and disable by default hrtimer dump code (this is too expensive
and specific to internal testing to leave in for debug mode even if
it's not printed). If you hack it enabled, it will dump the sul
list for the pt and assert if the list is disordered.
The sul callback is allowed to do anything to the sul list, it's
not possible to safely iterate it inbetween calls.
Luckily because it's sorted, we only ever care about the current
head, so switch to iterating it like that.
This shouldn't be necessary; just END_HEADERS flag should be enough.
But nghttp2 will not talk to us unless we end the stream from our side.
Unfortunately ending the stream at the time we sent the headers means
we cannot support the long poll half-close scheme. So add a quirk
flag to optionally support this behaviour of nghttp2 when the client
is creating the connection.
