On Tue, Oct 6, 2020 at 1:10 PM Roy T. Fielding <field...@gbiv.com> wrote: > > > On Oct 6, 2020, at 4:31 AM, sebb <seb...@gmail.com> wrote: > > > > Apart from a lack of console messages, how can one check if the socket > > is working properly? > > Maybe try something that fills in a form, like sending reminders. > You can cancel it after the form is filled, but the filling > seems to be done via websocket. I don't know if we are logging > the requests received via a websocket. > > I was able to send out the reminders on Monday, so your fix > worked for me.
Random, disjointed thoughts, in no particular order. 1) The only use of websockets by the board agenda application is for asynchronous, one-way messages from the server to the client, generally to provide updates to data that the client already has a stale version of. It would surprise me if being unable to obtain a websocket connection would affect forms in any way other than in the staleness of the content. (Note: I'm saying "it would surprise me", not that it can't happen. I'm often surprised). 2) The problems to date could all have been detected by simply attempting to open a websocket connection, nothing more is needed. If the socket can't be opened, it clearly is a problem. Down the road, it may be worth exploring additional tests, but this single test could be a good place to start. 3) Prior to websockets, I tried both eventsource and websockets hosted by the Apache webserver itself. Both lead to lock ups and even to crashing the VM due to out-of-memory errors. When I moved the websocket to a separate process and port, things worked better. Eventually the infra team firewalled that port, and I had the Apache webserver forward the requests to the process. When the client connected to the websocket process directly it made a lot of sense for that process to implement SSL. Now that that is no longer the case, it no longer is necessary. In fact, it no longer is necessary for the websocket to be running as root, as that is only done to enable it to access the certificates. > ....Roy - Sam Ruby > > On Mon, 5 Oct 2020 at 17:08, sebb <seb...@gmail.com> wrote: > >> > >> As you suspected, the failure was: > >> Cert does not match for name 'localhost' > >> > >> This fixes it, but may not be the best solution: > >> SSLProxyCheckPeerName off > >
