[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [libmicrohttpd] Libmicrohttpd - HTTP_UPGRADE example,
Christian Grothoff <=