Without this, it was impossible to connect to an existing session, because we
were trying to send messages to sessions that were not connected yet.
Change-Id: If9260a1f0ac8f5387f492541548724b0065df9d9
Don't block when creating new sessions, instead queue the requests, and handle
them in the DocumentBroker.
Change-Id: I200bbfc740f004c37178fa316d1eb91afdde5d4a
When we call readIncomingData() outside of the poll, we read the data, and
store them into the buffer. But then the next poll will not indicate that
there data actually some available (they've been already read from the FD),
and we will get stuck.
I susppect we should remove from the SSL case at some stage too, to be
symmetrict to the non-SSL case.
Change-Id: Ib8339400b41e797adb2eb8519f87093ebf6be9c5
Also dung out a chunk of older code.
FIXME: websocket / ClientSession needs to associate itself with the
DocumentBroker poll loop in place of the original loop.
Pull the notification pieces out of SigUtil.cpp - not signal safe,
and invoked only from LOOLWSD anyway.
In a non-blocking world, the socket close notification sends are
instant - so more work required to count-down / timeout remaining
clients.
SSL only requests what to poll for next.
So it's more accurate to rename ReadOrWrite
to Neither, since in that case SSL really
isn't blocked on either read or write.
Change-Id: I62dd4f94730d51666a7661b10a9d582d69fbf45e
No longer necessary to have them enabled
permanently, especially that they affect
performance significantly negatively.
Change-Id: I02ef99da00ba4ecb8e24647ee372a03d79d07fe7
With multipart streams the parsing isn't
done until all parts are in. We will need
to reparse the header when more data comes in
until we can parse all parts. Otherwise we
end up removing the header and losing it
when we can't find all parts in the body.
This fixes convert-to requests.
Change-Id: Ic1d5ccbd00fd6763eb91fdda35177f6df847f100
There are other types of frames than application
data.
Also a message can be composed of multiple frames.
Change-Id: Ia97349553b61ae05fa78854222808eaa43386c0e
These are really GET requests that aren't
WebSocket upgrade. Should rename to something
less misleading.
Re-enabled testSlideShow which depended on this.
Change-Id: I52b7f67b650fcdcbae7c2bff020b756099263141
Apparently if we don't send immediately after the upgrade
the first frame doesn't get parsed as WebSocket (at least
in Poco).
Change-Id: Ieb30afae1423d8352d81c79af568947d10fca1e6
It's necessary to do the SSL handshake
and to get the request (if we get there)
on accepting so by the time we poll we know
what SSL needs to do next. No reason to
read on first poll when we should be
expecting a request upon connection anyway.
Change-Id: I8eecaad5f8450075d45e487702972418cad125bc
When the socket is closed the last WS frame
will not have any payload, just a frame.
In this case the socket should still fire
handleMessage so this frame could trigger
application logic, however in this case
ClientSession has nothing to do, so we skip it.
Change-Id: Ia2b13026e31460ffceb8f9d9cfa39d36fbc57146
