https://gitlab.synchro.net/main/sbbs/-/commit/22c6721d6f926ba5fce85a54
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Remove unused assignment.

No need to get time() here since it's never checked.

Resolves CID 174292

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/6623cff0e3516937e38ae76a
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Always return 403 to requests for access.ars or webctrl.ini

Previously, 403 was only returned if they existed, and 404 if they
didn't.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/5d3de1eea3288155bc7a630e
Modified Files:
src/sbbs3/websrvr.c
Log Message:
For the cases we'll send a Content-Length of zero, do not send content.

Should fix #223
Introduced in d56ba01f which likely fixed some stuff on the wiki.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/bc5bfa5f6f9fb7208ed7bbe1
Modified Files:
src/sbbs3/websrvr.c
Log Message:
We still want the zero-length entity, just not any content.

Fixes last commit, which could cause infinite hangs on certain requests.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/b881935a0f28b65f66d6218c
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Track the active client "highwater mark" (highest number of concurrent clients)

Could be useful for knowing if you need to increase MaxClients for typical usage.

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

https://gitlab.synchro.net/main/sbbs/-/commit/9048b3d231b7ceeb823c2220
Modified Files:
src/sbbs3/websrvr.c
Log Message:
post_to_file() shouldn't close the file since it didn't open it.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/e2f3407c8cd1379184da9668
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Remove some unused variables.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/03b7b2f9443db9fa02989aec
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Fix socket descriptor leak in fastcgi_connect()

Found by Coverity-scan (CID 330051)

@Deuce should review this.

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

https://gitlab.synchro.net/main/sbbs/-/commit/22f130cad457cd21747dd6bc
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Fix resource leak in ssjs_send_headers()

IdArray returned by JS_Enumerate() was never freed.

Caught by Coverity-scan, CID 319627.

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

https://gitlab.synchro.net/main/sbbs/-/commit/9f7894575eed369cfd56ad40
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Remove incorrect and unnecessary comment.

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

https://gitlab.synchro.net/main/sbbs/-/commit/a487e0c681d380e01a76deeb
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Don't allow colons in web-requested path names on Windows

This fixes issue #269 (NTFS Alternate Data Stream vulnerability) and other potential pathname issues on Windows involving colons.

There are other illegal filename characters on Windows (e.g. <>|"?*), but filenames with these characters aren't expected to pass the later stat() test, so should fail with a 404 error.

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

https://gitlab.synchro.net/main/sbbs/-/commit/f38adc13f4b5169a0d59cbce
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Fix NULL pointer dereference in read_post_data()

What took down cvs/sbbs yesterday:
Program terminated with signal SIGSEGV, Segmentation fault.
6203 session->req.post_data[session->req.post_len]=0; [Current thread is 1 (Thread 0x7f2b989ff700 (LWP 17031))]
(gdb) print post_len
No symbol "post_len" in current context.
(gdb) print session->req.post_len
$1 = 0
(gdb) print session->req.post_data
$2 = 0x0

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

https://gitlab.synchro.net/main/sbbs/-/commit/f2858ee600525704d27011e0
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Add support for web request path aliases (defined in web_alias.ini)

Similar to the ctrl/ftpalias.cfg file, the new ctrl/web_alias.ini file (optional) can be used to map a portion (the first portion, only) of a web request path to a different physical or virtual path. For example, I'm using it to map:
/Synchronet/ = /files/main/sbbs/
for filebase access to my main->sbbs directory of Vertrauen's filebase using a /Synchronet/* web request (i.e. for slightly prettier or shorter custom URLs, if desired).

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

https://gitlab.synchro.net/main/sbbs/-/commit/005633b1fffb7b6df70cb13b
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Log requests that resolve outside of the web root as hack attempts

"Request for x is outside of the web root" was already logged (with a "NOTICE" log level), but would not sound the hack attempt alarm (on Windows) or log to the hack.log. Now it does.

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

El 15/1/22 a las 23:09, Rob Swindell escribió:

https://gitlab.synchro.net/main/sbbs/-/commit/f2858ee600525704d27011e0 Modified Files:
src/sbbs3/websrvr.c
Log Message:
Add support for web request path aliases (defined in web_alias.ini)

Similar to the ctrl/ftpalias.cfg file, the new ctrl/web_alias.ini file (optional) can be used to map a portion (the first portion, only) of a web request path to a different physical or virtual path. For example, I'm using it to map:
/Synchronet/ = /files/main/sbbs/
for filebase access to my main->sbbs directory of Vertrauen's filebase using a /Synchronet/* web request (i.e. for slightly prettier or shorter custom URLs, if desired).
---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net

alias portion (webrequest) can support multiple levels? like:

/ftp/main/ansis = /sbbs/data/main/ansis
/ftp/other/upload = /home/pepe/uploads

??

---
ï¿­ Synchronet ï¿­ Dock Sud BBS TLD 24 HS - bbs.docksud.com.ar

Re: Re: src/sbbs3/websrvr.c
By: Ragnarok to Rob Swindell on Mon Jan 17 2022 11:57 am

alias portion (webrequest) can support multiple levels? like:

/ftp/main/ansis = /sbbs/data/main/ansis
/ftp/other/upload = /home/pepe/uploads

Yes. But they likely should end in a '/' too.
--
digital man (rob)

This Is Spinal Tap quote #25:
Viv Savage: Have... a good... time... all the time. That's my philosophy. Norco, CA WX: 58.0øF, 80.0% humidity, 3 mph NW wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d8c099dbc962727df2723650
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Fix HTTP-requests for files >= 2GB in size

An int is 32-bits on all supported platforms, so this has always been broken. The actual file size/request-length sent would depend on fun 2's complement math (a 32GB file was being truncated to 433MB).

Also fixed some wrong uses of PRIuOFF: off_t is a signed integer, so technically the maximum file size you can request now is 2^63 bytes, which is "big enough".

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

https://gitlab.synchro.net/main/sbbs/-/commit/c0f42027dded92626251d686
Modified Files:
src/sbbs3/websrvr.c
Log Message:
I don't know what I was smoking when I did this, but it's fixed now.

Weird early failure return on TLS sends. Most noticible on local
(ie: fast) connections, but clearly stupid all around when you
look at the code.

Fixed, but some day, I should go back and look how we eneded up in
this mess.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/cd4066a287da2b52e7aec775
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Resolve warning about enum value not handled in switch() statement

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

https://gitlab.synchro.net/main/sbbs/-/commit/a7f6b8549d24feb43c83ee44
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Include client IP address in HTTP-level error log messages

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

https://gitlab.synchro.net/main/sbbs/-/commit/a82559e327b74c4513751593
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Use safe string formatting to squelch warnings

Attempt to address 2 GCC version 11.2.0 2 warnings reported by Nelgin
‘%s’ directive writing up to 3 bytes into a region of size between 1 and 4097

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/2e67162225de28219d747ed1
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Perform a JS garbage collection for each new request in a reused session

A reused HTTP session would never (apparently) perform garbage collection.
The evidence of this was the collection of concurrent user.dat file opens
that would never close until the HTTP sessions were closed. Hundreds or
even thousands of open user.dat's have been seen. After this change,
active web server (webv4 UI) users have not caused these spikes in open user.dat files, at least in my testing.

If no garbage collection was being performed, then likely a lot of JS
heap was being needlessly wasted, which could eventually result in a JS
"out of memory" error. But that's just a theory.

Investigation is needed into why the js_CommonOperationCallback()'s calls to JS_MaybeGC() were not sufficient to actually perform garbage collection
in this case.

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

https://gitlab.synchro.net/main/sbbs/-/commit/75bb2cf6633fb51f56a23e53
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Publish client highwater mark (max concurrent client stat) to MQTT

https://gitlab.synchro.net/main/sbbs/-/commit/75bb2cf6633fb51f56a23e53
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Publish client highwater mark (max concurrent client stat) to MQTT

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

https://gitlab.synchro.net/main/sbbs/-/commit/7fb6c7b4d8ec2150eefe55df
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Add missing argument to new error log message upone putuserdat() failure

Fixes a couple CIDs and a GCC warning

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

https://gitlab.synchro.net/main/sbbs/-/commit/d98359abefd58e43bb0e3115
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Move max concurrent connections check into http_session_thread()

We can't send a 4xx error (ie: client did something wrong) in
plaintext on a TLS connection.

Untested beyond a basic compile check.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/913092779871fdf4f4fc3e56
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Since this is after client_on() is called now, use > not >=

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/91125d1b721525a9c7720d0c
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Track and report the concurrent connections per client highwater mark

It's possible now for clients to easily exceed the configured max concurrent connections limit, even though they just get an error 429 page. Let's at least track and log when a new highwater mark is reached.

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

https://gitlab.synchro.net/main/sbbs/-/commit/ce7d83eeda506e5f366fe31d
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Add/use errprintf() to reduce severity of repeated error messages

Part of solution for issue #619 (for the web server)

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

https://gitlab.synchro.net/main/sbbs/-/commit/f2c891789734a9e783a1ac14
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Lower severity of repeated errors in js_ReportError()

This needed a custom solution (not errprintf) since the filename is passed-in is likely from dynamically allocated memory, so a pointer comparison isn't enough - and we don't get the function name.

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

https://gitlab.synchro.net/main/sbbs/-/commit/bbf9d5eac22ce15077a4599f
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Use errprintf() instead of lprintf() for one more log message

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

https://gitlab.synchro.net/main/sbbs/-/commit/a4ac0be63a49cc98f4883bef
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Better NULL ptr checking in js_ErrorReporter, CID 516068

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

https://gitlab.synchro.net/main/sbbs/-/commit/630b22ada39c50f871597b00
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Whitespace change only

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

https://gitlab.synchro.net/main/sbbs/-/commit/91b5a37ca1155f71f28c6eda
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Check return value of JS_NewStringCopyZ (for NULL)

Kind of a shot in the dark here: Max (WESTLINE) is reporting HEAP CORRUPTION debug assertion in websrvr.dll. In the 2 instances reported, a long (336
char) JSON "query value" was logged by apparent spam-bot trying to create a
a new user account ("send-me-free-stuff" is one of the JSON properties).

JS_NewStringCopyZ() can return NULL in a low memory situation, though I don't know that explains possible heap corruption.

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

https://gitlab.synchro.net/main/sbbs/-/commit/196ad130ca1a7fbecc73807b
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Use errprintf for FastCGI related error log messages

I received 6853 duplicate FastCGI error emails today (sent in a 2 minute
time span). I wish I already had this in place. :-(

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

https://gitlab.synchro.net/main/sbbs/-/commit/0afbc6a9ae33dc715e0125bc
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Fix NULL dereference when there are no directory vshortcuts defined

As reported by Accession in #synchronet at irc.synchro.net

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

https://gitlab.synchro.net/main/sbbs/-/commit/3618930a6e23a5f3b5709a71
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Resolve GCC warning enumeration value ‘PARSED_VPATH_x’ not handled in switch

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/0c6913fbd626457fb401aae8
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Another use of errprintf() to help de-dupe error logs/alerts

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

https://gitlab.synchro.net/main/sbbs/-/commit/48ac38bbbed74e4e98830c36
Modified Files:
src/sbbs3/websrvr.c
Log Message:
More use of errprintf() to reduce duplicate error log messages

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

https://gitlab.synchro.net/main/sbbs/-/commit/adf899cdeb60600fed167324
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Don't try to send 503 error for TLS connections that exceed maximum

since this doens't work and just generates/logs an error every time.

And for non-TLS connections, if the 503 send fails, just log it as a warning.

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

https://gitlab.synchro.net/main/sbbs/-/commit/8fe9b03cc155aee581fabce2
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Log output improvements

- include client protocol (HTTP or HTTPS) and IP address in more log messages
- include some more detail (e.g. send byte count) in "ERROR sending" message
- lower severity of "Executing FastCGI" log message from Info to Debug

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

https://gitlab.synchro.net/main/sbbs/-/commit/38fde64dab9f2684f33ca3a6
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Fix max concurrent connections limit

broken in commit d98359abefd58e4

It'd send a 429 error, but keep accepting and processing client
requests, thus not really limiting the concurrent clients (from the same
IP) ever.

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

https://gitlab.synchro.net/main/sbbs/-/commit/e712db6e16c730fe515f9ea6
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Immediately reject non-TLS connections that exceed concurrent connections limit

Further revert commit d98359ab at least for non-HTTPS/TLS connections, so we
no longer needlessly create threads just to send a 429 error.

This along with the previous commit have restored my web severs to sustainable operation after the recent huge increase in volume of requests from a huge number of unique IP addresses of *.googleusercontent.com

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

https://gitlab.synchro.net/main/sbbs/-/commit/14f0c3d11fda44d238ac4408
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Fix suspicion expressed by DigitalMan in IRC

Actually ensure the byte range starts with "bytes=".
If anyone defines something other than bytes in the future, this
will correctly give them an error instead of parsing everything after
the sixth byte as a byte range.

Also, fixes parsing of end-anchored ranges (ie: -100 and 100-)
and the special case of 0-0 (should send one byte)

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/80e8cdc85ac76f4763d04b15
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Don't log an error if failed to sent error 429

Who cares if we fail to send the error to the client? No one cares, that's who cares. No one. No one cares. </trump>

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

Re: src/sbbs3/websrvr.c
By: Rob Swindell (on Debian Linux) to Git commit to main/sbbs/master on Wed Jun 11 2025 05:17 pm

Who cares if we fail to send the error to the client? No one cares, that's who cares. No one. No one cares. </trump>

dont try to be funny. it doesn't work for you.
---
þ Synchronet þ ::: BBSES.info - free BBS services :::

https://gitlab.synchro.net/main/sbbs/-/commit/2c63bdb3fb7578360a3350f9
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Improve logging around SSJS-generated error page/sending

Reduce severity (to DEBUG) of "Using SSJS error page" message
Include protocol and IP address and error code in each message.

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

https://gitlab.synchro.net/main/sbbs/-/commit/2588c5cf72d9fe4a9e825f0e
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Increment local "served" count upon termination and include highwater mark

... in "Session thread terminated" log message

The "served" value logged wasn't monotonically incrementing since it was incremented before session threads were created/released, making the log message out of sync with reality.

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

https://gitlab.synchro.net/main/sbbs/-/commit/83c0999b76ef8ce0c77513a4
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Fix issue #942

Session is initialized to HTTP/0.9 (which doesn't send headers) and
the HEAD method (which doesn't send a body). This was caught in
writebuf(), which returned 0 due to the body not being sent, which
caused the error to be logged.

Set the values to HTTP/1.0 and GET so we can call send_error()
before we read a request line and actually send an error.

Additionally, add a LOG_INFO to writebuf() when it returns 0 due
to body being disabled to make this kind of thing easier to find
in the future.

Finally, don't attempt to send an error body if send_headers()
fails or if we should not send a body.

This would also allow us to send a 408 if we wanted to, but I've
never been convinced that's useful.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/76acaac000c1bba5e025f115
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Output the User-Agent header value as a info-level log message

Useful for tracking (some/most) bots

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

https://gitlab.synchro.net/main/sbbs/-/commit/2d4af7be9e8a92ebbbc4242b
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Reduce contention on protected-int thread_count

We can capture the new value upon atomic-decrement, use it

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

https://gitlab.synchro.net/main/sbbs/-/commit/4090d823bba9fa4630bd79c2
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Solve the active_clients exceeds configured max_clients issue

e.g. with [Web] max_clients configured for 200, the following could occur: sbbs: web 0522 HTTP [34.45.142.114] Session thread terminated (220 clients, 378 threads remain, 128627 served)

The issue was that the active_client count is incremented in the http_session_thread(), but was being checked in the main web server/listening thread.

So now we'll check in both threads, but allow more HTTPS/TLS client threads
(10 more) than the configured max, to allow for successfull sending of error 503 (up to a point), while HTTP (non-TLS) connections exceeding the configured max will be immediately dropped without creating a session thread.

We now no longer increment the client highwater mark for connections that exceed the maximum.

Also fix send_error() to not log the Connection: close\r\nContent-Length: 0\r\n portion of 503 errors.

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

https://gitlab.synchro.net/main/sbbs/-/commit/1f480068adc0ac59c5b4e663
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Apply max connections per IP limit to filter-exempted IPs

This exemption could (did) cause confusing "works for me" situations when testing max concurrent connections settings that may fail for others.

So, just because an IP address is listed in ctrl/ipfilter_exempt.cfg, no
longer means that clients at that IP are exempt from concurrent connection limits (from a single IP address).

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

https://gitlab.synchro.net/main/sbbs/-/commit/c0c3dbdf76d91f155a9371ca
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Revert "Apply max connections per IP limit to filter-exempted IPs"

This reverts commit 1f480068adc0ac59c5b4e6634dc827c52721a7da.

The other servers exempt ipfilter_exempt.cfg listed hosts still and it looks like I really need gitlab to be exempt from the concurrent connections limit for (all my) webhooks to work reliably since they run in parallel and I can't seem to configure that behavior in gitlab.

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

https://gitlab.synchro.net/main/sbbs/-/commit/a43ca30ea674ac77ca98d74e
Modified Files:
src/sbbs3/websrvr.c
Log Message:
Pad "HTTP" to 5 chars for protocol field in log messages

... aligning display for easier reading with non-proportional fonts.

Includes the client's protocol and IP address in JS log messages/errors.

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