[Webkit-unassigned] [Bug 220366] New: REGRESSION(r270074): [WPE][GTK] Problems when creating SoupServer in WebKitTestServer::WebKitTestServer

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=220366

            Bug ID: 220366
           Summary: REGRESSION(r270074): [WPE][GTK] Problems when creating
                    SoupServer in WebKitTestServer::WebKitTestServer
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at gnome.org
                CC: bugs-noreply at webkitgtk.org, fred.wang at free.fr,
                    pgriffis at igalia.com

Using libsoup (built from latest commit on gnome-3-38 branch), I notice that WebKitTestServer crashes whenever it is constructed, which prevents running API tests that use it. The error is:

Failed to start HTTP server: Can’t create a TLS server without a TLS certificate

Problem is here:

SoupServerListenOptions serverOptions = static_cast<SoupServerListenOptions>(options[ServerHTTPS] ? SOUP_SERVER_LISTEN_IPV4_ONLY : SOUP_SERVER_LISTEN_IPV4_ONLY | SOUP_SERVER_LISTEN_HTTPS);

Notice that the logic was inverted by mistake in r270074. We pass SOUP_SERVER_LISTEN_HTTPS only when options[ServerHTTPS] is not set. That is, whenever we should not be listening for HTTPS, we listen for HTTPS. And whenever we should be listening for HTTPS, we don't.

This leads me to question: how does anything currently work? I see API tests are actually currently passing on the release bots, so... ?????

I notice we also currently pass SOUP_SERVER_LISTEN_IPV4_ONLY to vanilla soup_server_listen(), which does nothing. We should probably stop doing that, so my suggested fix would be:

diff --git a/Tools/TestWebKitAPI/glib/WebKitGLib/WebKitTestServer.cpp b/Tools/TestWebKitAPI/glib/WebKitGLib/WebKitTestServer.cpp
index 2a0720fc3fdd..6baaaddad01d 100644
--- a/Tools/TestWebKitAPI/glib/WebKitGLib/WebKitTestServer.cpp
+++ b/Tools/TestWebKitAPI/glib/WebKitGLib/WebKitTestServer.cpp
@@ -45,14 +45,13 @@ WebKitTestServer::WebKitTestServer(ServerOptionsBitSet options)
         SOUP_SERVER_SSL_KEY_FILE, sslKeyFile.get(), nullptr));

     GUniqueOutPtr<GError> error;
-    SoupServerListenOptions serverOptions = static_cast<SoupServerListenOptions>(options[ServerHTTPS] ? SOUP_SERVER_LISTEN_IPV4_ONLY : SOUP_SERVER_LISTEN_IPV4_ONLY | SOUP_SERVER_LISTEN_HTTPS);
     bool serverStarted = false;
     if (options[ServerNonLoopback]) {
         GRefPtr<SoupAddress> address = adoptGRef(soup_address_new("localhost", SOUP_ADDRESS_ANY_PORT));
         soup_address_resolve_sync(address.get(), nullptr);
-        serverStarted = soup_server_listen(m_soupServer.get(), soup_address_get_gsockaddr(address.get()), serverOptions, &error.outPtr());
+        serverStarted = soup_server_listen(m_soupServer.get(), soup_address_get_gsockaddr(address.get()), options[ServerHTTPS] ? SOUP_SERVER_LISTEN_HTTPS : static_cast<SoupServerListenOptions>(0), &error.outPtr());
     } else
-        serverStarted = soup_server_listen_local(m_soupServer.get(), SOUP_ADDRESS_ANY_PORT, serverOptions, &error.outPtr());
+        serverStarted = soup_server_listen_local(m_soupServer.get(), SOUP_ADDRESS_ANY_PORT, options[ServerHTTPS] ? static_cast<SoupServerListenOptions>(SOUP_SERVER_LISTEN_IPV4_ONLY | SOUP_SERVER_LISTEN_HTTPS) : SOUP_SERVER_LISTEN_IPV4_ONLY, &error.outPtr());
     if (!serverStarted) {
         WTFLogAlways("Failed to start HTTP server: %s", error->message);
         CRASH();

Of course, if that worked, I would submit a proper patch. It doesn't work. serverStarted is true, so the listen call succeeds, but soup_server_get_uris() returns NULL, and then we crash. (A smaller patch that just swaps SOUP_SERVER_LISTEN_HTTPS around crashes the same way.) It smells like a libsoup bug. Surely if the call to listen() succeeds, then soup_server_get_uris() should return results?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210106/77629f14/attachment.htm>