removed use of Poco::StringTokenizer from the common directory
used LOOLProtocol::tokenize and std::vecor<std::string>
regex is used in Authorization.cpp due to limitation of toeknize mathod
regular expression helps to keep the original intention of the code
Change-Id: Ic87597d8b30cb385000f983389a57dc5d2533d98
Reviewed-on: https://gerrit.libreoffice.org/82575
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
The change causes problems for people on various sad distros. Oh well,
whatever.
This reverts commit bd00d9fd05.
This reverts commit 054a9cdb04.
Change-Id: Ie439e4c655d02b6f34bdd1a9c1c5b6db6048b653
It is is complicated enough to build the iOS app. Requiring GNU
libtool brings with it the risk of polluting the command environment
as there already is a completely different command in macOS with the
same name, /usr/bin/libtool. And as GNU libtool was used only to build
the unit tests for the "normal" server-based Online that are built and
run only on Linux anyway, we don't really need any of the
"portability" that GNU libtool brings.
Without GNU libtool, we compile all the $(wsd_sources) (see
test/Makefile.am) that the unit-* tests use into a single object file,
WsdSources.o. (Because they need to be compiled as PIC we can't use
the already compiled object files for the Online server programs.)
This required some additional minor changes to a few source files.
Change-Id: I20a2c523170376fa4c1a0d9d8d6b693a9779376f
Reviewed-on: https://gerrit.libreoffice.org/72840
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
This was a workaround to Poco's limitation
of requiring socket receiveFrame be given
preallocated buffer, which couldn't be
exceeded by a larger payload. This meant
the receiver had to know the maximum
payload in advance.
Since only the Kit uses Poco sockets,
and the Kit never receives large payloads,
this preamble is now obsolete.
100% (94/94) of old-style tests PASS.
Change-Id: I76776f89497409e5755e335a3e25553e91cf0876
Reviewed-on: https://gerrit.libreoffice.org/36037
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
If the socket is in error, SELECT_READ returns
immediatly as failure. In this case we sit
in a tight loop polling read over and over.
We now check for SELECT_ERROR when SElECT_READ
fails to properly close the socket and break.
When receiveFrame returns -1, we should first
check the flags for socket close, as that
is a legitimate case of returning -ve.
Change-Id: I7bbc948638a8395d28990ba92eddb9a1a9f1e6f2
Reviewed-on: https://gerrit.libreoffice.org/31932
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
It doesn't mean anything is wrong or that the connection would be in
some invalid or closed state, but just that we didn't actually receive
any "interesting" frame that could be handled in the caller.
When we the pipe with wsd is closed we
assume wsd has died and we terminate too.
WSD can fork us anew, if it's still alive.
Change-Id: I669ed717db973b50498a6bc08e1fca59c6563443
Reviewed-on: https://gerrit.libreoffice.org/31337
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Setting 'n = -1;' helps to detect where the failure happened
when receiveFrame throws. At the bottom of the function we log
partially processed data by checking n (among others).
This reverts commit 752372a2b0.
Change-Id: I3294329c3d95b38d72c3fc824ab2eb7f2339adee
Reviewed-on: https://gerrit.libreoffice.org/31339
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When receiving large messages the dynamic socket buffer
is resized to accomodate the incoming large message.
This buffer was previously never reduced in size.
This is an obvious leak that is now avoided.
When the buffer grows beyond quadruple the default
size, it is shrunk back to the default. This gives
a decent balance between memory waste and unnecessary
resizing up and down after each large message received.
Change-Id: Ic3996c80e96592af6f12c4abd1dd737bdc07b814
Reviewed-on: https://gerrit.libreoffice.org/31287
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Messages larger than a certain size are preambled
with a 'nextmessage' message that hold the size
of the subsequent message.
This is a workaround to a limitation the Poco
WebSocket API where if the buffer size is
smaller than the received frame the socket
ends up in a bad state and must be closed.
Unfortunately the new API that avoids this
workaround is not yet released by Poco.
Here we minimize the need for 'nextmessage'
to truely large messages. The limit is now
raised from above 1KB to over 63KB.
We may raise this limit further, but that will
cost each socket that much dedicated buffer size.
Change-Id: I01e4c68cdbe67e413c04a9725152224a87ab8267
Reviewed-on: https://gerrit.libreoffice.org/31286
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
