libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] Libmicrohttpd - HTTP_UPGRADE example


From: Christian Grothoff
Subject: Re: [libmicrohttpd] Libmicrohttpd - HTTP_UPGRADE example
Date: Sun, 14 Jul 2013 19:33:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

Hi!

Here are my current thoughts on websockets/HTTP UPGRADE for MHD.

1) the usual idea of websockets / HTTP "upgrade" is to give "the" TCP stream to 
the
   application and let them do whatever they want with it; the natural 
abstraction
   here is to give the *socket* to the application (on both ends)
2) this fails with HTTPS, as there we have to encrypt/decrypt and thus we do not
   have a "native" TCP socket to give to the application, as each read/write has
   to go through the encryption first
3) MHD philosophy says that there should be virtually no difference between 
writing
   server code for HTTP and HTTPS, so returning a socket for HTTP and a 
read/write
   API for TLS/HTTPS is not a good option either.

My current thoughts:
1) for HTTP, return the socket
2) for HTTPS, also return a socket, except make it a 'unixsocket' or 
TCP-loopback
   (on W32); then, MHD should *internally* forward from that artificial socket
   to the encryption/decryption routines for HTTPS; that way, except for issues
   like setting TCP options (getsockopt, setsockopt, ioctl) the HTTP/HTTPS-APIs
   would indeed by identical, and they'd be the "nice" read/write/recv/send APIs
   everybody would like for websockets.

Possible issues:
* we have a bunch of threading modes; most are unproblematic with the above 
design,
  but the 'thread-per-connection' might not be; once we return the socket to the
  application, we'll need the thread to handle the forwarding --- should we then
  expect the application to start a SECOND thread for the same connection to 
handle
  the websocket?
* testing --- we usually use libcurl in our testcases, but I've not found
  'HTTP UPGRADE' support in the libcurl documentation; this means that for
  testing (and this feature definitively needs a good test) we might need to
  roll our own (minimal) HTTP client; doable, but extra work.

This is again different from what I wrote in Nov 2012 on this list and instead
goes back to the API I suggested in January 2012, but as you can see I'm quite
torn on what the API _should_ really look like, which is (in addition to me
being busy with other things) one of the main reasons why little has happened
in this area...

Anyway, please re-read the respective old threads on the mailinglist (1'12, 
11'12)
before hacking up anything --- and do consider HTTP/HTTPS-issues, the various
threading modes and testing.  Also, MHD should definitively only support
'HTTP UPGRADE' and then leave it to the application (or some other library)
to implement websockets or whatever else happens then.

My 2 cents.

Happy hacking!

Christian


On 07/14/2013 07:00 PM, address@hidden wrote:
> Hi, i think implementing websocket in libmicrohttpd. I'm very grateful if
> you could give me some advices.
> Thank you very much.
> 
> 
> Giovanni



reply via email to

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