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 <[email protected]> > > 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<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 <[email protected] <mailto: >> [email protected]**>> >> >> >> 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 >> >> >> >> >> >> >> >> >> > >
