Would there be interest for a pull request which replaces the makefiles with a CMake build implementation?

This change will help maintain & improve the cross platform support.

It would be beneficial if I could build Civetweb for multiple versions of visual studio for instance.

Thoughts?

Following up on my prior question: we got the HTTP functionality (data format conversion) working properly with embedded CivetWeb, and we're now adding the HTTPS support. All the OpenSSL DLLs are (apparently) where they're supposed to be, and the configurations are set.

It looks to me like all the relevant settings are good to go in web.config:

listening_ports=8083, 8443s
ssl_certificate server.pem
ssl_cipher_list = DES-CBC3-SHA:AES128-SHA:AES128-GCM-SHA256
ssl_protocol_version = 3

I noted that the MD for OpenSSL doesn't mention doing something like

callbacks.init_ssl = [](void *, void *) { return 1; };

but we sorted that out on our own.

Anyway--to the issue: The log is happy (no complaints about the PEM, nor about the DLLs).

Firefox says SSL_ERROR_NO_CYPHER_OVERLAP, Chrome says ERR_SSL_VERSION_OR_CIPHER_MISMATCH, Postman just says it can't chat with the server, and IE spins. And spins. And spins.

I followed up on all the articles I could find about ensuring that Chrome gets the cert added, but I'm up against a deadline here and I can't even figure out how to debug this. I could have a bad config, have missed a step in the coding--it could be a lot of things.

Supposedly this is setting up for TLS1.2 but I can't confirm that. Should I be barking up this tree, up the OpenSSL tree, or some other tree? (The application will be queried by .a NET 4.5 application, not a browser, but the .NET end is even fussier in my experience.) Can you (or anyone reading this) point me in the right direction?

Thanks,

--jbm!

I need to use SSL for webhook callbacks but my provider refuses to accept SSL as handled by civetweb.

You can test it here (this test will accept specific ports to test): https://www.htbridge.com/ssl/

It receives a grade of C while port 443 on my server receives a A+

"The server is vulnerable to POODLE over SSL"

""SERVER DOES NOT HAVE CIPHER PREFERENCE The server does not have preferred cipher suites. We advise to enable this feature in order to use only the strongest suite available."

"SERVER SUPPORTS CLIENT-INITIATED SECURE RENEGOTIATION The server supports client-initiated secure renegotiation which may be unsafe and allow Denial of Service attacks."

The build script uses #!/bin/sh but then calls set -o pipefail. These are incompatible. Either use #!/usr/local/bin/bash or similar or drop the -o option to pipefail.

Casting pthread_t to unsigned long fails in the compiler. This related code should be upgraded to use the correct CRYPTO_THREADID_ semantics. Failing that, just using the default (thread-local errno behaviour) is sufficient.

I gave up with problems patching luasqlite and went back to v1.7 so there may be other problems.

There's a data race on ctx->stop_flag during shutdown. Didn't see an easy fix so creating an issue instead of a PR.

WARNING: ThreadSanitizer: data race (pid=748655)
  Write of size 4 at 0x7b5c00000028 by main thread:
    #0 mg_stop src/civetweb.c:18842:17 (objectbox-http-server-test+0x26cd7f)
    #1 CivetServer::close() src/CivetServer.cpp:398:3 (objectbox-http-server-test+0x2833e8)
    #2 CivetServer::~CivetServer() src/CivetServer.cpp:329:2 (objectbox-http-server-test+0x2833e8)

  Previous read of size 4 at 0x7b5c00000028 by thread T1:
    #0 master_thread_run src/civetweb.c:18625:14 (objectbox-http-server-test+0x277935)
    #1 master_thread src/civetweb.c:18725:2 (objectbox-http-server-test+0x277935)

  Location is heap block of size 888 at 0x7b5c00000000 allocated by main thread:
    #0 calloc <null> (objectbox-http-server-test+0x7b468)
    #1 mg_calloc src/civetweb.c:1540:9 (objectbox-http-server-test+0x26d151)
    #2 mg_start2 src/civetweb.c:18973:34 (objectbox-http-server-test+0x26d151)
    #3 mg_start src/civetweb.c:19548:9 (objectbox-http-server-test+0x26d151)
    #4 CivetServer::CivetServer(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, CivetCallbacks const*, void const*) src/CivetServer.cpp:321:12 (objectbox-http-server-test+0x2830de)

  Thread T1 'civetweb-master' (tid=748660, running) created by main thread at:
    #0 pthread_create <null> (objectbox-http-server-test+0xb07ce)
    #1 mg_start_thread_with_id src/civetweb.c:6049:11 (objectbox-http-server-test+0x26e920)
    #2 mg_start2 src/civetweb.c:19482:9 (objectbox-http-server-test+0x26e920)
    #3 mg_start src/civetweb.c:19548:9 (objectbox-http-server-test+0x26e920)
    #4 CivetServer::CivetServer(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, CivetCallbacks const*, void const*) src/CivetServer.cpp:321:12 (objectbox-http-server-test+0x2830de)

SUMMARY: ThreadSanitizer: data race src/civetweb.c:18842:17 in mg_stop

Using the NO_TIMEGM option disables the caching feature. Civetweb will not be able to detect a unchanged file. On the other hand it allows to build civetweb on systems that don't implement timegm().

I use "mg_set_request_handler" to hook the specified URI to my handler.

for example, "curl https://127.0.0.1/%2e/SECURE_API/neverseen.txt" and "curl https://127.0.0.1/./SECURE_API/./neverseen.txt"

If I use "." in my url, it looks like curl will remove "." from request url. If I use "%2e", it will send to civetweb directly and the conn->request_uri will be "/./SECURE_API/./neverseen.txt".

For the case, my request handler is never be matched. The worse is that my URI filter will be bypass using "%2e".

I see function "remove_double_dots_and_double_slashes" will try to remove "..". Maybe we should remove ".", too.

This environment works:

Environment: compiler=msvc-18-seh, build_shared=NO, no_files=NO, enable_ipv6=NO, enable_ssl=YES, enable_websockets=YES, no_cgi=NO; Platform: x86

This one fails:

Environment: compiler=msvc-18-seh, build_shared=NO, no_files=NO, enable_ipv6=NO, enable_ssl=YES, enable_websockets=YES, no_cgi=NO; Platform: x64

Note, the only difference is in the failure is in the 64bit windows version.

Here is the summary:

  Test project C:/projects/civetweb/output/build
        Start  1: test-private-http-message
   1/19 Test  #1: test-private-http-message ...................   Passed    0.04 sec
        Start  2: test-private-url-parsing
   2/19 Test  #2: test-private-url-parsing ....................   Passed    0.02 sec
        Start  3: test-private-internal-parsing
   3/19 Test  #3: test-private-internal-parsing ...............   Passed    0.00 sec
        Start  4: test-private-encode-decode
   4/19 Test  #4: test-private-encode-decode ..................   Passed    0.01 sec
        Start  5: test-private-mask-data
   5/19 Test  #5: test-private-mask-data ......................   Passed    0.01 sec
        Start  6: test-publicfunc-version
   6/19 Test  #6: test-publicfunc-version .....................   Passed    0.01 sec
        Start  7: test-publicfunc-options
   7/19 Test  #7: test-publicfunc-options .....................   Passed    0.01 sec
        Start  8: test-publicfunc-mime-types
   8/19 Test  #8: test-publicfunc-mime-types ..................   Passed    0.01 sec
        Start  9: test-publicfunc-strcasecmp
   9/19 Test  #9: test-publicfunc-strcasecmp ..................   Passed    0.01 sec
        Start 10: test-publicfunc-url-encoding-decoding
  10/19 Test #10: test-publicfunc-url-encoding-decoding .......   Passed    0.01 sec
        Start 11: test-publicfunc-cookies-and-variables
  11/19 Test #11: test-publicfunc-cookies-and-variables .......   Passed    0.01 sec
        Start 12: test-publicfunc-md5
  12/19 Test #12: test-publicfunc-md5 .........................   Passed    0.00 sec
        Start 13: test-publicserver-check-test-environment
  13/19 Test #13: test-publicserver-check-test-environment ....   Passed    0.02 sec
        Start 14: test-publicserver-start-threads
  14/19 Test #14: test-publicserver-start-threads .............   Passed    1.16 sec
        Start 15: test-publicserver-start-stop-http-server
  15/19 Test #15: test-publicserver-start-stop-http-server ....   Passed    3.25 sec
        Start 16: test-publicserver-start-stop-https-server
  16/19 Test #16: test-publicserver-start-stop-https-server ...***Failed    1.03 sec
        Start 17: test-publicserver-tls-server-client
  17/19 Test #17: test-publicserver-tls-server-client .........***Failed    1.02 sec
        Start 18: test-publicserver-server-requests
  18/19 Test #18: test-publicserver-server-requests ...........***Failed    0.00 sec
        Start 19: test-exe-helper-funcs
  19/19 Test #19: test-exe-helper-funcs .......................   Passed    0.02 sec

  84% tests passed, 3 tests failed out of 19

  Total Test time (real) =   7.04 sec

I think if test-publicserver-start-stop-https-server, test-publicserver-start-stop-https-server, test-publicserver-start-stop-https-server were to be run directly (seperately from CTest), it would give more useful information about the test failure, but CTest is suppressing that information.

An alternative could be to turn on XML logging and have the xml files be uploaded to appveyor as test results.

Here is the link explaining uploading: https://www.appveyor.com/docs/running-tests#uploading-xml-test-results here is the link explaining how to do xml logging in libcheck: ftp://www.eeng.dcu.ie/pub/ee454/cygwin/usr/share/doc/check-0.9.2/html/x232.html

mg_read has a function param of void* buf, but also declares a local variable char buf[64].

This should be fixed as it generates a warning with -Wshadow on clang. I can look at it later but figured I'd give you a heads up.

Hello,

I have succesfully compiled and run embedded_cpp.cpp in my QT Qt5.5.1-mingw492 environment using below: https://github.com/civetweb/civetweb/blob/master/examples/embedded_cpp/embedded_cpp.cpp

And now I have put my index.html and its dependency files like css, js, image files to the DOCUMENT_ROOT folder, the index.html file itself can be loaded into my chrome browser but got below error in chrome console. All the files are correctly placed in the corresponding path.

What is missing and how should I resolve the problem? I tried the precompiled binary files CivetWeb_Win32+64_V1.9.1.zip and it works very well, confused what is missing from my side...

Any help is highly appreciated!

Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH http://localhost:8081/static/css/AdminLTE.min.css Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH http://localhost:8081/static/js/plugins/jQuery/jQuery-2.2.0.min.js Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH http://localhost:8081/static/js/plugins/bootstrap/bootstrap.min.js Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH app.min.js:13 Uncaught Error: AdminLTE requires jQuery at app.min.js:13 http://localhost:8081/static/js/vendor.ad881d6cc3a38d459a3a.js Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH http://localhost:8081/static/js/app.f2ad0f34e4204ad3234c.js Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH

I am using websocket on the same ports as a http server. I can connect fine via ws, http and https, but when I try to connect wss nothing happens. I get a error code 1000 (normal disconnect). Is this broken or s there something special I have to do beyond ws/http/http to get wss to work?

How do I turn on the DEBUG_TRACE logging in Civet APIs?

My code which uses civet web APIs is failing somewhere in mg_write and I want to debug it further. There are not enough logs to understand what could be the issue. I have enabled error_log_file and access_log_file.Would like to know how to get trace level info as well.

Hi! This may be a stupid and/or beginner question but I have spent the last couple of days trying to figure out what the best solution for this might be:

I have my document root directory set, containing a few static HTML files I want to serve whenever the user navigates to, for example, /admin/foo. I would now like to "secure" all files within the "admin" dir using a cookie / token based authentication method. My idea was to utilize the CivetAuthHandler to catch all requests to any site located within the "admin" dir, check the cookie and if it is still valid, serve the HTML file as if nothing ever happened (as if it was served statically without the handler intervening). If the cookie is not valid I would redirect the user to the login page.

The content on the secured page would not change depending on the user, so it could still be totally static, I just need some very basic access control (doesn't even really need to be that "secure").

Serving the file statically works just fine but when I try to use the CivetAuthHandler the things I print to the connection from within the handler are the only things that get displayed and the original HTML document within the root just gets ignored.

Is there a way to use the handler and if the authentication was successful simply continue serving the file in the document root corresponding to the entered URL? Or should this be tackled differently using civetweb? (I need to be able to provide my own login form so I am guessing that using the digest access authentication is out of the question)

Any help would be highly appreciated! Thanks!

When accessing a directory from a browser, if index_files is set, civetweb will issue a 301 - Redirect, and provide a new URL in the "Location" header.

In version v1.15 and earlier, the Location value is specified relative to the URL root. E.G. http://127.0.0.1:8080/A/B is redirected to /A/B/. The browser interprets this as http://127.0.0.1:8080/A/B/, and a subsequent request from the browser uses the index.html file transparently without the browser being aware.

In the latest version (commit c6e4e33b7863745b3a6af89cea78eecc8b509ac8 at time of writing), the Location header instead specifies a complete URL including the domain, using the authentication_domain value to populate the URL. E.G. http://127.0.0.1:8080/A/B is redirected to http://mydomain.com/A/B/. This causes a failed CORS request because the authentication_domain value was intentionally not set.

This appears to be defective behavior because:

• It is not documented either for authentication_domain or index_files.
• This behavior prevents deliberately exposing the web server with multiple public-facing addresses.
• Local-environment testing scenarios must either override the authentication_domain or use hostname hacks to experience the same behavior as higher environments.
• This behavior has changed since v1.15, and is a breaking change.

1. At unittest/private.c:71, we have the following statements:

START_TEST(test_parse_http_message) {
//...
char req8[] = "HTTP/1.0 404 Not Found\n\n";
//...
//  req8 is a valid response
ck_assert_int_eq(lenreq8, get_http_header_len(req8, lenreq8));
ck_assert_int_eq(-1, test_parse_http_request(req8, lenreq8, &ri));
ck_assert_int_eq(lenreq8, test_parse_http_response(req8, lenreq8, &respi));

But according to rfc7230 (https://www.rfc-editor.org/rfc/rfc7230):

3.1.2. Status Line

The first line of a response message is the status-line, consisting of the protocol version, a space (SP), the status code, another space, a possibly empty textual phrase describing the status code, and ending with CRLF.

 status-line = HTTP-version SP status-code SP reason-phrase CRLF

So req8 does not seems to be valid. Instead, a valid response would have to be:

char reqX[] = "HTTP/1.0 404 Not Found\r\n\r\n";

2. A variation of that issue happens when civetweb reports a 404 to a client that makes a request to an invalid endpoint, causing trouble with some HTTP client libraries that can't find the "double CRLF" marking "end of header" (as per the RFC above) but only one CRLF. Seems that it's handled by mg_send_http_error with no body condition.

Calling mg_store_body() with a relative path like: "../../path/to/file.txt" does not work. It works if converting the path to an absolute one like => "c:/install_dir/path/to/file.txt"

Is this an intended behavior? If so I think it should be documented.

Tested on Windows, civeweb 1.15