These are chat archives for IndySockets/Indy

9th
Mar 2017
Sergey
@icegood
Mar 09 2017 13:24
No, Remy. I'm just waiting in debugger
Jeroen Wiert Pluimers
@jpluimers
Mar 09 2017 14:26
@rlebeau the thing here is that the other ends are embedded devices with firmwares that sometimes are not that well implemented. Solving this has been suspended until I've worked around https://plus.google.com/+JeroenPluimers/posts/Nze9sDEFb7S but I will get back on it later.
Sergey
@icegood
Mar 09 2017 15:30
@rlebeau I don't actually see how Indy works with WideString. The only way i see that there is an overriden version of TIdIOHandler.Write for type=string. But i have rather old version of Delphi with 1-byte sring, so i wonder how in such a system Indy would know how correctly deal while writting WideString?
Remy Lebeau
@rlebeau
Mar 09 2017 18:13
@icegood my point is, by making Indy wait before it calls SSL_connect(), you are delaying the SSL/TLS handshake, and the underlying socket, or even the other party, may time out and fail the connection, which will then be reported by OpenSSL when it finally tries to finish the handshake.
@icegood Indy uses (Wide|Unicode)String internally when converting strings <-> bytes. TIdIOHandler has a DefStringEncoding property, and Write(String) has an optional AByteEncoding parameter (defaulting to DefStringEncoding if not specified), to control (Wide|Unicode)String <-> bytes conversions. In pre-Unicode versions of Delphi and FreePascal where String=AnsiString, TIdIOHandler also has a DefAnsiEncoding property, and Write(String) has an optional ASrcEncoding parameter (defaulting to DefAnsiEncoding if not specified), to control the Ansi charset/codepage used for AnsiString <-> (Wide|Unicode)String conversions.
Remy Lebeau
@rlebeau
Mar 09 2017 18:23
@jpluimers that does not change what I said earlier. Regardless of client implementation, an HTTP server has final say over how HTTP keep-alives are used. An HTTP server is not required to honor a keep-alive request from a client, period. So there is no reason that you cannot set TIdHTTPServer.KeepAlive=False even if the clients are using HTTP 1.1. If the server closes a connection after sending a response, and the clients are not smart enough to reconnect on their next request, that is their own fault, not the server's.
Jeroen Wiert Pluimers
@jpluimers
Mar 09 2017 18:25
The problem is that if we send the response, then immediately disconnect, some clients do not process the response and resend their same request.
Remy Lebeau
@rlebeau
Mar 09 2017 18:29
@jpluimers Then that is on them, not the server. But whatever. You have buggy clients. If you must use KeepAlive=True, then setting the connection's ReadTimeout is about all you can do for now to close the connection after a few extra seconds of waiting.
Ludwig Behm
@lbehm
Mar 09 2017 19:41
Is there any way to access the SSL_CTX of a TIdServerIOHandlerSSLOpenSSL and then also use it with SSL_CTX_set_options() from C++ (Berlin)?
Trying to "improve" my HTTPS server after @mezen mentioned it...
Remy Lebeau
@rlebeau
Mar 09 2017 19:49
TIdServerIOHandlerSSLOpenSSL and TIdSSLIOHandlerSocketOpenSSL both have an SSLContext property which contains the SSL_CTX, but it is protected, so you will have to define an accessor class to reach it, eg: class TIdSSLContextAccess : public TIdSSLContext { public: __property SSL_CTX* Handle = {read=fContext}; }; ... SSL_CTX_set_options(static_cast<TIdSSLContextAccess*>(IOHandler->SSLContext)->Handle, ...);
Ludwig Behm
@lbehm
Mar 09 2017 19:51
and is there a way to access SSL_CTX_set_options? isn't in the hpp header files
Remy Lebeau
@rlebeau
Mar 09 2017 19:52
SSL_CTX_set_options() is just a macro around SSL_CTX_ctrl(). You would have to access it from the OpenSSL SDK directly, not from Indy's headers
Ludwig Behm
@lbehm
Mar 09 2017 19:54
okay... any hints how to do that?
Remy Lebeau
@rlebeau
Mar 09 2017 19:55
Um, add the relavant #include statements to your C++ code for the OpenSSL header files, and link to the OpenSSL DLL. Just like accessing any other DLL function
Ludwig Behm
@lbehm
Mar 09 2017 19:57
of course... nervermind^^