Rather than the very C-like API we currently have, accepting a void* and
a length, let's take a Bytes object instead. In almost all existing
cases, the compiler figures out the length.
This adds support for WebSocket subprotocols to WebSocket DOM
objects, with some necessary plumbing to LibWebSocket and its
clients.
See the associated pull request for how this was tested.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
Frames with large payloads may arrive in multiple chunks, so it's not
safe to assume that the whole frame is available for reading just
because we got a first "ready to read" notification.
This patch solves this in a very naive way by simply buffering incoming
frame data and trying to reparse a frame every time new data arrives.
This is definitely inefficient, but it works as a start.
With this, it's now possible to log in to Discord in Ladybird! :^)
The LibCore sockets implementation becomes WebSocketImplSerenity.
This will allow us to create a custom WebSocketImpl subclass for Qt
to use in Ladybird.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
read_length in WebSocket::read_frame is used to track how many bytes we
have read in from the network. However, we was subtracting the number
of read in bytes instead of adding, underflowing it to about the 64-bit
unsigned integer limit.
This effectively limited us to only doing one read from the network.
This was only an issue if the server stalled when sending data,
which is especially common for large payloads. This would also cause us
to go out of sync. This meant when a new frame came in, we would read
the payload data of the previous frame as if it was the frame header
and payload of the next frame.
This allows us to read in the initial payload from Discord Gateway
that describes to the client the servers we are in, the emotes the
server has, the channels it has, etc. For an account that's only in
the Serenity Discord, this was about 20 KB (compressed!)
According to RFC 6455 sections 5.5.2-5.5.3 Ping and Pong frames
can have empty "Application data" that means payload can be of size 0.
This change fixes failed "buffer.size()" assertion inside
of Core::Stream::write_or_error by not trying to send empty payload
in WebSocket::send_frame.
As LibTLS now supports the Core::Stream APIs, we can get rid of the
split paths for TCP/TLS and significantly simplify the code as well.
Provided to you free of charge by the Core::Stream-ification team :^)
Apologies for the enormous commit, but I don't see a way to split this
up nicely. In the vast majority of cases it's a simple change. A few
extra places can use TRY instead of manual error checking though. :^)
We don't want to destroy the WebSocketImpl while we're still using it
higher up the stack. By using deferred_invoke(), we allow the stack
to unwind before actually destroying any objects.
This fixes an issue with the WebSocket service crashing on immediate
connection failure.
This was caused by a double notifier on the TLS socket, which caused
the TLS code to freak out about not being able to read properly. In
addition, the existing loop inside of drain_read() has been replaced by
code that actually works, and which includes new warnings when the
drain method is called before initialization is done or after the
websocket gets closed.
The WebSocket service isolates communication with a WebSocket to its
own isolated process. Similar to other isolating services, it has its
own user and group.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *