• src/sbbs3/websrvr.c

    From rswindell@VERT to CVS commit on Wednesday, May 22, 2019 13:39:25
    src/sbbs3 websrvr.c 1.680 1.681
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv23025

    Modified Files:
    websrvr.c
    Log Message:
    open_post_file(): if post_data is NULL, just log an error and return NULL (don't pass a NULL pointer to fwrite() which can assert or crash).



    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Wednesday, May 22, 2019 15:40:03
    src/sbbs3 websrvr.c 1.681 1.682
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv8139

    Modified Files:
    websrvr.c
    Log Message:
    Increase MAX_POST_LEN from 1MB to 4MB (QWK REP packets can be > 1MB) -
    I think that > 1MB post data is supported, but the http_request.post_data
    property won't be created if the length > MAX_POST_LEN. Perhaps would just
    store the post data in a file (uh, it already is?) and expose the filename to
    JS scripts? It'd be a lot cleaner than storing the data in a file and then
    reading (or mem-mapping) the file and then copying the contents into a JS
    property.

    Allow the JS http_request.post_data property to contain NULs.

    open_post_file() will now open the post file (and return the FILE*) even if
    session->req.post_data is NULL, it just won't try to write to the file if the
    post_data is NULL.

    mem-map the large post data files using XPMAP_WRITE (read/write) rather than
    XPMAP_READ (read-only) - without this change, this line in read_post_data()
    would cause an exception:
    session->req.post_data[session->req.post_len]=0;
    Now, we seem to have the potential of an off-by-one here (if the length
    mem-mapped is not post_len + 1), but that isn't happening. <shrug>

    Fixed a couple of FILE pointer/descriptor leaks if post_to_file() failed.

    Changed name of post data file to SBBS_POST.*.*.data (it's not necessarily html).

    So now, uploads > 1MB work, but questions remain:
    - wouldn't PUT be a more appropriate method (than POST) for file uploads?
    - how can we support post_data > MAX_POST_LEN (now 4MB) in JS?



    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Friday, June 07, 2019 10:46:47
    src/sbbs3 websrvr.c 1.682 1.683
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/home/rswindell/sbbs/src/sbbs3

    Modified Files:
    websrvr.c
    Log Message:
    Fix observed segfault (NULL pointer dereference) in parse_headers
    (strtok can return NULL).



    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Friday, June 21, 2019 09:54:31
    src/sbbs3 websrvr.c 1.684 1.685
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv8336

    Modified Files:
    websrvr.c
    Log Message:
    Some RFC nits.

    1) Send Content-Length even if we will be closing the connection.
    2) Send the highest HTTP version in the status line that has the same major version.



    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Tuesday, July 02, 2019 20:17:49
    src/sbbs3 websrvr.c 1.686 1.687
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv27170

    Modified Files:
    websrvr.c
    Log Message:
    send_headers() is called twice for chunked data. The second time is required for additional headers and the final terminating CRLF.




    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Wednesday, July 03, 2019 16:53:30
    src/sbbs3 websrvr.c 1.687 1.688
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv4323

    Modified Files:
    websrvr.c
    Log Message:
    As with CGI, if a script specifies a Content-Length or Transfer-Encoding header, don't calculate either one and let the script shoot itself in the
    foot.

    Also, if a Location header is set, try an internal redirect rather than
    forcing the client to handle it.

    Now scripts can avoid chunked mode by specifying a correct content-length
    if the content-length is wrong though, Bad Things will happen.




    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Wednesday, July 03, 2019 16:57:42
    src/sbbs3 websrvr.c 1.688 1.689
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv4962

    Modified Files:
    websrvr.c
    Log Message:
    Update to last commit... only allow fiddling with things if the initial
    headers haven't been sent yet.




    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From rswindell@VERT to CVS commit on Tuesday, July 23, 2019 23:52:19
    src/sbbs3 websrvr.c 1.690 1.691
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv15156

    Modified Files:
    websrvr.c
    Log Message:
    Store the configured temp directory for the web server in scfg.temp_dir so that JS scripts using system.temp_dir to store files get a sensible value (and not the hard-coded default of just "temp").
    This should fix the creation of ctrl/tempftelnet.url files.



    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Friday, August 02, 2019 08:10:08
    src/sbbs3 websrvr.c 1.691 1.692
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv18463

    Modified Files:
    websrvr.c
    Log Message:
    Fix an error nobody has ever seen.



    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Friday, August 02, 2019 08:26:09
    src/sbbs3 websrvr.c 1.692 1.693
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv20335

    Modified Files:
    websrvr.c
    Log Message:
    Add a terrible hack to see if the TLS POST issue is what I think it is.




    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Friday, August 02, 2019 08:47:07
    src/sbbs3 websrvr.c 1.693 1.694
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv23121

    Modified Files:
    websrvr.c
    Log Message:
    De-hack and maybe fix?



    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Friday, August 02, 2019 08:50:36
    src/sbbs3 websrvr.c 1.694 1.695
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv23687

    Modified Files:
    websrvr.c
    Log Message:
    Don't crash of rd is NULL.



    ---
    ■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net
  • From deuce@VERT to CVS commit on Friday, August 02, 2019 08:52:02
    src/sbbs3 websrvr.c 1.695 1.696
    Update of /cvsroot/sbbs/src/sbbs3
    In directory cvs:/tmp/cvs-serv23917

    Modified Files:
    websrvr.c
    Log Message:
    Better anti-crash behaviour.




    ---
    ■ 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 Saturday, November 25, 2023 20:27:48
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sunday, December 17, 2023 17:53:23
    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
  • From Deuc┬┐@VERT to Git commit to main/sbbs/master on Monday, December 18, 2023 23:58:19
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Tuesday, December 19, 2023 20:20:18
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Thursday, January 04, 2024 19:17:35
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sunday, January 07, 2024 19:19:40
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Monday, January 15, 2024 21:14:44
    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
  • From Deuc┬┐@VERT to Git commit to main/sbbs/master on Wednesday, February 07, 2024 14:58:35
    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
  • From Deuc┬┐@VERT to Git commit to main/sbbs/master on Friday, February 09, 2024 09:07:36
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Tuesday, February 13, 2024 23:38:15
    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
  • From Rob Swindell (on ChromeOS)@VERT to Git commit to main/sbbs/master on Wednesday, February 14, 2024 00:28:02
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Thursday, February 15, 2024 22:55:31
    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
  • From Deuc┬┐@VERT to Git commit to main/sbbs/master on Wednesday, February 21, 2024 07:47:10
    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