Requests need to be introspected and
dispatched to the appropriate handler.
File serving, admin, POST request, etc.
are all valid types that we need to support.
But of course the primary one is the WS request
to load to and interact with a document.
Change-Id: Id2c3214deb6b54b06b2735ec3370f09ed7a1ae51
We don't need a special "WebSocket" class, as websocket itself is just an
upgrade of an existing socket / connection, and trying to come up with a
concept where a Socket class magically upgrades to a WebSocket class would be
messy.
So let's have just a WebSocketHandler, that communicates over a StreamSocket
or SslStreamSocket, and be done with that :-)
Change-Id: I449e4d662fbe2c5b1789e308053e4a71376fe481
Introduce the appropriate interface instead of the template, so that we can
de-couple the ResponseClient from the Socket itself.
Change-Id: I21892bbce5d83a18ca580a25cfc2efbb05b08705
ConsoleCertificateHandler will block on stdin
when a certificate error occures. This is hardly
helpful to users. Although in a server environment
this is likely to go to the journal, we should
properly log it and shutdown, rather than hang
waiting for the unlikely console input.
Change-Id: I54bb38ec60f443c579ef20dbb759941fae182e5b
SSL's decryption frame is 16kb, so it
makes sense to read by that multiple
for efficiency reasons.
Change-Id: Ib5d7b5bfc18fa1b27bcbc9aac93350c4e1292874
Reviewed-on: https://gerrit.libreoffice.org/34451
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
We now always read new data, because
SSL might need to process internal buffers,
and call the app message handler as long
as it keeps consuming data.
Finally, we write when we have data
to flush, even if we didn't get POLLOUT
event, because SSL might need to do
handshake, which is handled by the write
handler.
Change-Id: I909333c3a0492b0830044d51ae478ac5981b1d90
Reviewed-on: https://gerrit.libreoffice.org/34448
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
We expect to have more data if the buffer was
filled completely. Otherwise, there is no
reason to suspect there is more data, unless
we hope to have received time in that short
interval, which is not very likely.
Change-Id: I9a3dcb6378e8dcfa0d49b6c7ea92d7cec6690787
Reviewed-on: https://gerrit.libreoffice.org/34446
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The new test sends data of of 1 byte to
N bytes and expects the exact same data
returned in response.
This tests both buffering sizes and
websocket frames.
Change-Id: Ic6232b4e899d82d90a0ee7c96e4852ffaaf8e958
Reviewed-on: https://gerrit.libreoffice.org/34441
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
SSL expects the write buffer to be the same on
retry. This requirement cannot be guaranteed
when using standard containers as the internal
memory might be re-allocated between calls.
Luckily SSL can relax this requirement when asked.
Change-Id: I26771609a8cc0f9de0e554f9fa255d998f6c7b14
Reviewed-on: https://gerrit.libreoffice.org/34440
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
