1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/sbbs3/websrvr.c

    From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Jun 4 21:41:25 2025
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Tue Jun 10 23:11:08 2025
    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
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Jun 11 12:09:13 2025
    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
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Jun 11 12:44:06 2025
    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
  • From Deucе@VERT to Git commit to main/sbbs/master on Wed Jun 11 15:08:20 2025
    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
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Jun 11 17:17:15 2025
    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
  • From MRO@VERT/BBSESINF to Rob Swindell (on Debian L on Wed Jun 11 22:46:15 2025
    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 :::
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Thu Jun 12 21:55:34 2025
    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
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Jun 12 21:57:52 2025
    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
  • From Deucе@VERT to Git commit to main/sbbs/master on Sun Jun 15 03:07:18 2025
    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
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Mon Jun 16 19:06:06 2025
    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
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Mon Jun 16 19:06:06 2025
    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
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Jun 18 18:01:15 2025
    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
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Jun 18 18:01:15 2025
    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
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Jun 18 21:21:55 2025
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wed Jun 18 21:58:33 2025
    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