[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libmicrohttpd] upgrading connection

From: José Bollo
Subject: [libmicrohttpd] upgrading connection
Date: Wed, 20 Apr 2016 14:28:46 +0200

Hi all,

I implement web-socket upgrading and it worked very well with firefox.
The bad happens when I use Chromium. The following little patch of the
function 'keepalive_possible' of 'connection.c' solves the issue:

--- a/connection.c
+++ b/connection.c
@@ -733,8 +733,7 @@
     if (NULL == end)
       return MHD_YES;
-    if ( (MHD_str_equal_caseless_ (end, "close")) ||
-         (MHD_str_equal_caseless_ (end, "upgrade")) )
+    if ( (MHD_str_equal_caseless_ (end, "close")) )
       return MHD_NO;
    return MHD_YES;

Explanation: I use MHD_suspend_connection and MHD_resume_connection to
handle the connection that MHD created (MHD listens and creates
connections). The connection is suspended in the callback
MHD_OPTION_NOTIFY_COMPLETED, after sending the HTTP reply 101 'switching
protocols'. I enjoy that MHD can send the reply.

But chromium emits the header "connection: upgrade\r\n" when firefox
emits the header "connection: keep-alive, upgrade\r\n". This has the
effect that the connection is closed unexpectedly for chromium but not
for firefox.

So here is my mind: (1) there is a bug in 'keepalive_possible' that
doesn't handle multiple keys for 'connection' (but maybe HTTP states
that only one key is possible, I haven't checked) (2) my patch is the
smallest one that solves my problem (3) what is the official path for
upgrading a connection? If none, do you agree that the use of
suspend/resume is a good idea? If yes, the patch should be upstreamed to
avoid the closing of the connection when "connection: upgrade\r\n"

Best regards
José Bollo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]