@rlebeau Found thenew BPI files will make sure they are the ones that I am using. What about cdlIPIndyImpl190.bpl ?
@rlebeau Oh. These were the original bpls that I had:
IndyCore190.bpl
IndyIPClient190.bpl
IndyIPCommon190.bpl
IndyIPServer190.bpl
IndyProtocols190.bpl
IndySystem190.bpl
These were date 12/7/2013
However, after I compiled the 5 DPK files I only had
IndyCore190.bpl
IndyProtocols190.bpl
IndySystem190.bpl
These 3 replaced the 5 above as I removed the 5 above.
@rlebeau The .pas file are all new. idHTTP.pas was created on 12/15/2016 , IdHTTPHeaderInfo.pas was created 12/28/2015. does that sound right ?
@rlebeau Need to get a bite to eat. Can't think straight anymore.
@rlebeau Knocking off for the night. I really need a drink after this. Will cleanup environment tomorrow.
Even if a client only supports HTTP 1.1+, the server always has final say in keep-alive handling. You could just set TIdHTTPServer.KeepAlive=False, that will work just fine for HTTP 1.1 clients. On the other hand, TIdHTTP and TIdHTTPServer currently support the 'Connection: keep-alive' header to keep a connection open, but they do not yet implement the 'Keep-Alive: <timeout>' header to timeout and close an open connection between requests. In TIdHTTPServer, at least, when KeepAlive=True, you could try setting the AContext.Connection.IOHandler.ReadTimeout property in the OnConnect event and let Indy raise an exception and close the connection if the client does not send any traffic within the timeout period. That won't really address DoS attacks, though.
We need KeepAlive=True because some of the HTTP clients expect that.
@jpluimers That is highly doubtful. All compliant clients are expected to support the 'Connection: close' header. The HTTP spec makes it clear that just because 'Connection: keep-alive' is the default behavior for an HTTP 1.1 request does not guarantee that all servers will use 'Connection: keep-alive' on their responses. HTTP keep-alives are always negotiated, never assumed or guaranteed (client asks for a keep-alive, the server responds yay or nay). And besides, if the server closes its end of the connection after sending a response, clients have no choice but to close their ends as well. Any TCP socket implement has to deal with the possibility of closed/lost connections and reconnects. HTTP is stateless, there is no guarantee that a connection will stay alive from one request to the next, so any HTTP client has to be prepared to reconnect on each new request if necessary
Hi there!
I have a question regarding latest build of Indy Sockets for VCL:
In IdIOHandler in all versions of Read/Write for integers we have parameter AConvert: Boolean = True . I wonder in which cases it is useful to have AConvert= False? If we are interest in reliable tcp/ip protocol we have to run pairs of HostToNetwork and NetworkToHost calls. I mean we shouldn't do any assumptions about endianness of both client and server.
I have a question regarding latest build of Indy Sockets for VCL:
In IdIOHandler in all versions of Read/Write for integers we have parameter AConvert: Boolean = True . I wonder in which cases it is useful to have AConvert= False? If we are interest in reliable tcp/ip protocol we have to run pairs of HostToNetwork and NetworkToHost calls. I mean we shouldn't do any assumptions about endianness of both client and server.
@icegood MOST binary-oriented protocols want multi-byte integers to be transmitted in network byte order, so AConvert defaults to True to ensure outgoing integers are sent in network byte order, and incoming integers are returned in host byte order. But, there are some protocols that don't specify/require network byte ordering. AConvert is provided as an option for those cases where integers are not transmitted in network byte order. Yes, that is rare, but such protocols do exist.
@mezen that is typically true. However, to be more accurate, you are not limited to just OpenSSL, any SSL IOHandler will do, OpenSSL is just the default provided by Indy. And while all Indy TCP clients will create and assign a default non-SSL IOHandler object for you if one is not already assigned, there is currently only one component, TIdHTTP, that will actually create a default SSL IOHandler object for you.
The problem on why i ask is how correctly pass WideString type?
Hmm, i found smth strange in OpenSSL (not for fix just knowledge sharing). If i wait more 20 sec right before call of SSL_connect(fSSL) in TIdSSLSocket.Connect i do obtain SSL_ERROR_SYSCALL.
@rlebeau , i read both http://stackoverflow.com/questions/35987485/eidosslconnecterror-error-connecting-with-ssl-eof-was-observed
and your comment in TIdSSLSocket.Connect regarding that but my case is not in negotiation. Actually if i omit that time delay then connection is OK!
@rlebeau , i read both http://stackoverflow.com/questions/35987485/eidosslconnecterror-error-connecting-with-ssl-eof-was-observed
and your comment in TIdSSLSocket.Connect regarding that but my case is not in negotiation. Actually if i omit that time delay then connection is OK!
@icegood ENDIAN_BIG and ENDIAN_LITTLE are defined by the FreePascal compiler. The Delphi compiler does not define endianess conditionals, so Indy manually defines ENDIAN_LITTLE for Delphi. Either way, you don't need to worry about endianess to work with WideString (or UnicodeString in D2009+). Indy deals with endianness internally when needed.
@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.
@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?
@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.
@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.
Trying to "improve" my HTTPS server after @mezen mentioned it...
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, ...);
New to this forum. I have a problem installing Indy 10 for Delphi 2010 (Delphi 2010 came with RAD Studio). I will try to describe the problem in as few words as possible. To install the version of Indy I am using I have removed everything related to Indy that came with Delphi. That is, everyting related to Indy in the C:\Program Files (x86)\Embarcadero\RAD Studio\7.0\bin, lib and source directories. I have then copied a downloaded version of Indy to the three folders C:\Program files (x86)\Embarcadero\RAD Studio\7.0\source\Indy\Indy10\Core, Protocols and System and added all three paths to the Library Paths setting. I then build the downloaded IndySystem140.bpl, IndyCore140.bpl, IndyProtocols140.bpl, dclIndyCore140.bpl and dclIndyProtocols140.bpl, in that order. This works fine. I get the problem even with just two projects using Indy. The first one builds fine. The second one builds too. However, when I go back to build the first one again I get the error "[DCC Fatal Error] IndyCore140.dpk(91): F2051 Unit IdContext was compiled with a different version of IdGlobal.IdDisposeAndNil". If I rebuild the 5 Indy BPLs it works once more to build my two projects, but after both of my projects have been built the same situation occurs again. That is, the first project cannot build and gives me that error message. I don't know where to start searching for the solution to the problem. Neither IdContext.dcu nor IdGlobal.dcu seem to get recompiled after the BPLs were first built so I don't get why it complains about the versions not matching. The Indy version was downloaded at 2015-12-28 and it HAS worked fine before, however on this new computer I am setting up I cannot get it to work without this frustrating problem. I am reluctant to use a different version of Indy if I don't really really have to. The version from 2015-12-28 has been very stable. It is used in a very critical system that just HAS to work. Any suggestions for how to resolve this would be extremely appreciated.
Just checked again and IdGlobal does get recompiled but not IdContext. So, after the second project gets built they no longer have the same time stamp. Is this the problem? I thought Delphi was supposed to recompile everything that needed to be recompiled so this situation should never happen?