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
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
Because the socket can be freed while a separate
thread is sending data via the handler, we must
have a locked reference to the socket instance
in the handler.
Change-Id: Iefad3fc2b147f96b8d538d9edd7cac3fce25b5bf
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
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
When two sockets send data to each other in blocking
mode, they can both wait until the other end-point's
buffers are free enough to receive the data being
sent. Since in LOOLWebSocket we lock both send and
receive with the same lock, this prevents the
reader thread from freeing the buffer while we try
to send data. But since our peer is in the same
dilemma, neither of us will make progress--deadlock.
Since sockets are full-duplex, they are capable of
handling two way communication concurrently. Poco
seems to not share data between them either, so
this seems safe.
Change-Id: I1fd68cd4fb3b4250b93c8f94cd42e49ee78f6650
Reviewed-on: https://gerrit.libreoffice.org/34194
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
