[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"
appears.
Best regards
José Bollo
- [libmicrohttpd] upgrading connection,
José Bollo <=