sendFrame() implemented in LOOLWebSocket is thread safe, and also deals with
large messages - sends the "nextmessage: size=..." frame before the actual
large frame.
The problem this is attempting to solve was that when sending a large frame,
it was split to multiple packets. During that, another frame was sent from a
different thread; which lead to confusion, and the resulting frame was
corrupted (because it ended up composed from unrelated packets).
Change-Id: Ie85952e431b1cad2fdc6e3c64df8a444ea0ae971
This implements a new feature 'OwnerTermination' for WOPI based
hosts. WOPI hosts now have to enable this feature by mentioning
'EnableOwnerTermination' as 'true' in their CheckFileInfo
response. If the OwnerId of the file matches that of the UserId
of the session, this session would be able to terminate all other
sessions currently editing the same document.
The reason for this kind of document termination is sent to all
sessions in a new application-level 'close:' message. This new message is
similar to the CLOSE frame of WebSocket protocol which doesn't
seem to work across all browsers as of now. Eg: Chrome -
https://bugs.chromium.org/p/chromium/issues/detail?id=426798
After receiving this 'close: ' message, loleaflet acts
accordingly and tells the WOPI host why the websocket was closed
via post message API.
Change-Id: I997aa2e7805157ed599a3946a877fd32477cee1b
The missing init of mutexes is probably theoretical, the TraceFile and
the Unit ones were real errors, I think.
Change-Id: If19c23a9c93d34059998346af8d45c26a34043a6
Convert-to API got broken in
80786cc79d
In case of convert-to API, there is no actual client facing
websocket connection (and we use an invalid websocket
connection). So, when prisoner session tries to forward messages to
client it would fail as we have now started to propagate errors
from forwardToPeer.
Introduce a headless (without an actual client) peer mode, and
fail silently when someone tries to forward messages to such a peer.
Change-Id: I8a9f93f798dca9fea45c41e99bf373cd23d32e2c
A source file (.cpp) must include its own header first.
This insures that the header is self-contained and
doesn't depend on arbitrary (and accidental) includes
before it to compile.
Furthermore, system headers should go next, followed by
C then C++ headers, then libraries (Poco, etc) and, finally,
project headers come last.
This makes sure that headers and included in the same dependency
order to avoid side-effects. For example, Poco should never rely on
anything from our project in the same way that a C header should
never rely on anything in C++, Poco, or project headers.
Also, includes ought to be sorted where possible, to improve
readability and avoid accidental duplicates (of which there
were a few).
Change-Id: I62cc1343e4a091d69195e37ed659dba20cfcb1ef
Reviewed-on: https://gerrit.libreoffice.org/25262
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
loleaflet can now send userinactive when the user
has switched tabs or the browser window loses
focus. Similarly, it can send useractive when
focus is regained.
Change-Id: Id3186949b10a8263e29ada1a790d3123a79e8f08
Reviewed-on: https://gerrit.libreoffice.org/24272
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The closing handshake.
Either peer can send a control frame with data containing
a specified control sequence to begin the closing handshake.
Upon receiving such a frame, the other peer sends a
Close frame in response, if it hasn't already sent one.
In case of abnormal termination of session from client-side,
we might still have data being processed in the kit process, for
example, during auto-save. Trying to send such data over an
expired socket towards the client would throw exceptions which
need to be handled, otherwise the auto-save process would not be
successful. Further, the unhandled exception can bring the document
broker in an unstable state with dockey still present in the
object.
Also do not send 'editlock: 0' to a websocket session which is
going to be removed because the session might have been
forcefully terminated from the client-side, in which case sending
data would go nowhere.
Change-Id: I10eb9c818bc81d4db26d5a19dc8bd44f6fbdf32c
A call to Log::error() should be enough to indicate that it is an
error. We don't need to prefix the message with the string "Error: "
in some cases but not others. (If we do want such a prefix for all
errors, surely then we should add it in the actual Log::error()
function.)
Also, change some more Log::error() calls to Log::syserror() where
appropriate.
Sorry, could not resist. Obviously not very important.
In retrospect, maybe it would have been better to have as policy to
*not* use any 'using Poco::Foo'. Now there is an inconsistent mix of
writing out the complete type and using a 'using'. Plus copy-pasted
long lists of 'usings'. And of course, one should never have 'using'
in an include file. Oh well.
There are cases when prisoner would send huge text data but
without preceeding 'nextmessage' frames making the master throw
WebSocketException.
Also move the 'nextmessage' frame interpretation logic up in the
'else if' ladder to be able to detect and handle such huge text frames.
Change-Id: Ibe44b69f4ab75c1b8096648c6006316c88366e7c
Reviewed-on: https://gerrit.libreoffice.org/21835
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
