Re: [libmicrohttpd] HTTP "UPGRADE" header / switching protocol

[Bertrand Baudet]

Hi,

Actually, for my own small Proof Of Concept, I don't need HTTPS.

So HTTPS was out of my scope...

In addition, I'm not too familiar with the way how HTTPS works.

Regards,

Bertrand

2012/8/14 Christian Grothoff <address@hidden>

Hi!

The patch overall seems fine and follows the idea of the API; however, it doesn't address the main failing of the API: it doesn't work with HTTPS. Ideally, we'd want a solution where the programmer won't have to worry about HTTP vs. HTTPS at this level. The current API which exposes the underlying socket cannot work this way as we cannot (safely, nicely) offer a socket that has the same nice read/write/close functions and works with HTTPS (who would be responsible for running encryption/decryption and cleaning up afterwards, especially if, say, we're running without threads)? So we need to revisit the API,  as I'm not sure we want to do it *exactly* like this.  Maybe we need just some additional tiny handshake so that we can somehow terminate the interaction properly if HTTPS is involved?  I'm currently thinking that the best option for HTTPS + Upgarde would be to create a unixpipe (is there a W32 equivalent!?) and have MHD forward data read from the HTTPS decryption to the pipe and read from it, passing the data to the HTTPS encryption.  That we could keep doing inside the same connection handling logic (thread, select) that was used for the original connection (which would then NOT be fully terminated as it is now for HTTP).

Here, the question is if this can be done on W32. Alternatively, we could change the current socket-handle based API to one where we provide read/write/close callbacks to the response hander, but I'm not sure if that is so nice.

Opinions?  Again, ideally client code should look the same for HTTP/HTTPS and GNU/W32 systems.  The current patch doesn't even consider HTTPS...

Happy hacking!


Chrisitian

On 08/14/2012 05:14 PM, Bertrand Baudet wrote:

Hi,

Attached is a small patch to provide 'Connection: Upgrade' capability, with an attempt to do a test with curl.
The test is not fully functional since there are some issues with the use of curl:
* if the HTTP response code is '101' curl_perform will fail. I didn't look at curl source to understand why...
* the test attempt to do an upgrade to PTTH (http://tools.ietf.org/id/draft-lentczner-rhttp-00.txt), but reverting the use of a FD in a same process,
is not really easy. You end up reading the FD you just wrote at the same end of the connection and no data are read.

Anyway, I have done another sample test and the tcpdump capture looks OK.

Regards,
Bertrand

2012/8/8 Christian Grothoff <address@hidden <mailto:address@hidden>>

    Short answer: nothing has happened since.  IIRC the proposed API
    still had some issues (but I don't recall which ones right now),
    and nothing has been implemented by me (and I have received no
    patches or specific feedback  on the API).  It's still on my
    agenda, but I'm currently focused on other issues...

    Happy hacking,

    Christian


    On 08/08/2012 05:29 PM, Bertrand Baudet wrote:

        Hello,

        I found a thread regarding this subject on Mon Jan 23, 2012:
        'Websockets'.
        At this time an API for the upgrade mechanisms was proposed
        and it seems present in SVN, but '#if 0'.

        I'm interesting in using a protocol switch (not for websocket)
        and I would like to know if more have been done on this subject?

        Regards,
        Bertrand