https://gitlab.synchro.net/main/sbbs/-/commit/6697e52d90e024eb602aa2ac
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Don't try to send 0-byte files

Saves some opening, reading, and logging, but otherwise was harmeless.

Fix issue #422

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/5546278f0146522c886cca18
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Open SBBS_SSJS.*.html response file(s) only when actually writing data

The first write to a the temporary SBBS_SSJS.*.html file will open the file. This should reduce the number of 0-byte files left laying around in the the temp directory, which shouldn't be happening in the first place.

Also:
Fixed bug noticed in temp file clean up loop: POST data files would *also*
be retained when the DEBUG_SSJS option flag is set.

Also:
Replace some unsafe string operations with safe equivalents.

Happy Thanksgiving Nelgin!

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/274efc589d79d20711f04da2
Modified Files:
src/sbbs3/websrvr.c
Log Message:
A little clean-up around FILE* opening/closing, error handling

"HTTP Logging" replaced in log messages with "Web Server access-logging".

Using new FCLOSE_OPEN_FILE macro to close and NULify open FILE*'s.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/786add2421406f8f9ed9e113
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Replace IPv6 colons in access-log filenames with exclaimation marks on Windows

Colons are not legal filename characters on Windows and when virtual hosts are enabled, the IPv6 address of the server may be used in the access-log filename so we need to clean that up or errors opening/creating the access-log files occur.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b4f04d357b85fcb615dd400e
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Log client address in "Sending file" and "Sent file" log messages

For symmetry

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/df3d7d09a69ec2fdf20a0d73
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Ensure do_cryptInit() is called before calling lock_ssl_cert()

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/6180a88022c5d1e3f3a02dcd
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Look in mods dir for FileIndexScript before the exec dir

... unless the full path was specified.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/850a6595d70e78025c5a8f29
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Don't pass a TLS session ID of 0 js_CreateCommonObjects() for non-TLS sessions

The proper sentinel value here for "no TLS session" is -1, not 0.

This, at minimum, was causing a lot of extraneous calls to destroy_session() (from js_socket.c's do_js_close()) with an invalid (hopefully, not
otherwise used) cryptlib session ID of 0.

Nothing checks or logs the return value of destroy_session(), but I'd expect
it to be failing ... a lot.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ec45b264572304e92c3e0839
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Log an error if ssl_sync() fails, for W6RAY

Hopefully help debug why HTTPS isn't working for him

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/5bea6c6be1f0e73a35176920
Modified Files:
src/sbbs3/websrvr.c
Log Message:
If socket is closed while in sess_sendbuf(), don't log a warning message

... with a socket descriptor value of -1.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b973a74765fb50b36c045713
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Fix off_t printf warning.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/5bd8253c7c482272b9a4ea1f
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Temporary workaround for TLS issue.

It appears that if the timing is "just wrong", a large POST can
cause TLS to fail. This has shown up as an inability to edit
pages in the wiki.

This is not a fix however, but simple a workaround until this is
root-caused.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/6326f6d0d33019f5af7b31fb
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Set javascript callback "terminated" flag to true when recycling

(or terminating) the server.

This will allow background JS threads to terminate when recycling, so the server doesn't just hang indefinitelyi when recycling.

Add more logging in cleanup() when waiting for children threads to terminate.

Also, eliminate the global 'terminate' variable, answering the question:
Can this be changed to a if(ws_set!=NULL) check instead?

Yes, yes it can.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/95be5a80e00eebcb23370f92
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Simplify the child thread wait loop in cleanup()

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/8d7d9eb22fbabde369e6ab31
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Lower severity of "Response file path is NULL" log msg from CRIT to WARNING

This is not a completely unexpected thing to happen during ungraceful termination

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/50be44416dbf437e93f0f283
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Pass user_t as pointer.

Silly to pass a 728-byte object as a parameter.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3711e03ad615c3183aa401b4
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Use volatile keyword to (maybe) fix CID 488122: Data race condition

Ideally, I'd use atomic_bool instead, but we're using an older WinSDK for Win7 compatibility and so... can't.

Perhaps an xpdev 'protected_bool_t' should be created.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/90de10cf0dc28c25fab197b4
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Grow another 4-byte string.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/920902f3db4c4eac5ebcaf57
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Fix bug with error files (e.g. 404.html) introduced in commit 90de10cf

Deuce expanded the local 'error_code' buf to not trip the SAFECOPY macro destionation buffer length check. Only this buffer needed to be 4 chars
exactly to truncate the 'message' string at 3 chars (e.g. just "404" for an error message string that starts with "404 "). Switch from SAFECOPY to strlcpy to eliminate this bug.

As reported by Ragnarok as part of issue #748

The web error files should work again.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/984e76515378b50e3593ca8e
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Update the previous commit to revert the error_code length to 4, since we can

And use sizeof, not the magic number (again).

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net