Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 30 17:36
    alejandrolaorden commented #436
  • Jan 30 17:36
    alejandrolaorden commented #436
  • Jan 29 22:06
    alejandrolaorden commented #436
  • Jan 29 21:24
    rlebeau commented #436
  • Jan 29 17:25
    alejandrolaorden commented #436
  • Jan 28 01:58

    rlebeau on Indy11-preparation

    Updating TIdSocketList.Add() on… (compare)

  • Jan 27 18:00

    rlebeau on master

    #445 Updating TIdSocketList.Add… (compare)

  • Jan 27 17:19
    rlebeau labeled #445
  • Jan 27 17:19
    rlebeau labeled #445
  • Jan 27 17:19
    rlebeau labeled #445
  • Jan 27 17:19
    rlebeau assigned #445
  • Jan 27 17:19
    rlebeau edited #445
  • Jan 27 13:50
    MaxRusov edited #445
  • Jan 27 13:28
    MaxRusov opened #445
  • Jan 17 17:13
    rlebeau commented #225
  • Jan 17 12:50
    tothpaul commented #225
  • Jan 14 02:25

    rlebeau on Indy11-preparation

    Bringing in some more updates f… (compare)

  • Jan 13 17:12
    hafedh-trimeche closed #444
  • Jan 13 16:57
    rlebeau commented #444
  • Jan 13 16:56
    rlebeau commented #444
Sam B
@SamBirnbaum
@rlebeau Hi, Trying to follow the instructions that I downloaded and I am running into a problem. I removed Indy10 from the IDE, removed all the associated files from all the folders. I opened IndySystem190.dpk and I compiled it. It is not generating the bpl file so that the next step compiling IndyCore190.dpk can't find the IndySystem190. What am I doing wrong - Need help
Remy Lebeau
@rlebeau
@SamBirnbaum Yes, it should be generating the BPLs. It likely just puts it where you are not expecting. Did you search the IDE's normal output paths? Like %MyDocuments%\RAD Studio\<version>\Bpl? Since you are dealing with C++, you might consider trying Malcolm Smith's precompiled binaries (http://www.mjfreelancing.com/indy.htm). It is not the absolute lately SVN version of Indy, but it is close.
Sam B
@SamBirnbaum
@rlebeau Actually I am dealing Delphi, but I have the product that has C++ as well. I placed the download software in the folder c:\Indy10 so I will search the entire C drive and see if it placed it somewhere. BTW, there is a Group project for 190, what is that for ?
Sam B
@SamBirnbaum
Found it. I guess I should have put the downloaded software in a folder under rad studio. Will have to redo it after I come back from the airport.
Thanks again. Sorry for bothering you.
Remy Lebeau
@rlebeau
@SamBirnbaum Indy doesn't need to be put under RAD Studio's folder (I don't do that). As for the Project Group, that allows you to compile and install all 5 Indy packages at one time instead of individually.
Sam B
@SamBirnbaum
@rlebeau Hi, still receiving the same error 502 bad gateway. I remove all the dcu's that I thought might be needed to be regenerated and I still get the same error. Is it possible the XE 5 is the problem ?
Remy Lebeau
@rlebeau
@SamBirnbaum I don't see how, since this is an HTTP issue, not a Delphi issue
Sam B
@SamBirnbaum
@rlebeau I agree with that statement but we know that your exe worked. What other dcu's should be removed ? and from where ?
I am assuming that all the required *.pas files are in the download file indy10_5396.zip
Remy Lebeau
@rlebeau
@SamBirnbaum yes
@SamBirnbaum did you check to make sure your updated app is now sending a different HTTP request and not the old one?
Sam B
@SamBirnbaum
@rlebeau That is weird. The accept-encoding still has identity in it.
Also I am getting an error about loading dclIPIndyIpll190.bpl - Not a valid win32 application
Remy Lebeau
@rlebeau
@SamBirnbaum then you are not using the newer Indy version, your app is still compiling against the old version
Sam B
@SamBirnbaum
@rlebeau I removed all the dcu's and replaced them with the ones that were downloaded.
@rlebeau All the old DCUs were moved to sub directories.
Remy Lebeau
@rlebeau
@SamBirnbaum what about the old PAS and BPI/BPL files?
Sam B
@SamBirnbaum
II can trap the traffic to the location where the header is being built. Will let you know.
The old pas files and the bpl files. Did not know about the BPI files. What are they ?
Remy Lebeau
@rlebeau
@SamBirnbaum link libs for the BPLs
Sam B
@SamBirnbaum
@rlebeau The pas files are all new (dated 3/1/2017) let check on the bpi files
@rlebeau Found thenew BPI files will make sure they are the ones that I am using. What about cdlIPIndyImpl190.bpl ?
Remy Lebeau
@rlebeau
@SamBirnbaum dcl BPLs are design-time packages. IPIndyImpl is not an Indy package, it is an Embarcadero package that uses Indy internally for things like DataSnap and such.
Sam B
@SamBirnbaum

@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.

Remy Lebeau
@rlebeau
@SamBirnbaum The only packages that belong to Indy are IndySystem, (dcl)IndyCore, and (dcl)IndyProtocols, the rest are Embarcadero's.
Sam B
@SamBirnbaum
@rlebeau Ok. I will move them back into that directory. HAve to find again where the header is being prepared.
@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.
Sam B
@SamBirnbaum
@rlebeau Will be back shortly
Sam B
@SamBirnbaum
@rlebeau ITS ALIVE :) :) :) Can't thank you enough.
@rlebeau Knocking off for the night. I really need a drink after this. Will cleanup environment tomorrow.
Jeroen Wiert Pluimers
@jpluimers
What would be a good defense mechanism on a server against HTTP clients keeping the connection open indefinitely with sending very little traffic?
mezen
@mezen
Do the clients are sending valid HTTP traffic?
Jeroen Wiert Pluimers
@jpluimers
Not always. Basically it's part of my previous questions on throttling. Basically this is to harden a server against wrong traffic and high loads of traffic (not even DoS or DDoS though I'm interested in preventing that as well.).
Matthijs ter Woord
@mterwoord
hmm, disable http keep alive? ie, revert back to http 1.0?
Jeroen Wiert Pluimers
@jpluimers
Some clients do not support http 1.0 and require keep alive; but they do keep communicating and never keep alive for more than like 60 seconds.
Remy Lebeau
@rlebeau
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.
Jeroen Wiert Pluimers
@jpluimers
I'll try the last suggestion.
We need KeepAlive=True because some of the HTTP clients expect that.
Remy Lebeau
@rlebeau
@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
Sergey
@icegood
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.
Sergey
@icegood
I also converting one project fro indy9 to indy10. And i wonder, whether should i create new component ioHandler (i beleive TIdIOHandlerStack) for old TIdFTP component? Or Indy does it for me?
mezen
@mezen
If you dont set an explicit IOHandler to your component (TidTFP, TidHTTP, etc.), Indy creates an own default IOHandler. But if you need TLS Support, you have to set an openssl io handler.
Remy Lebeau
@rlebeau
@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.
Sergey
@icegood
hi again. Is $ENDIAN_BIG defined in delphi or indy?
The problem on why i ask is how correctly pass WideString type?
Sergey
@icegood
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!
Remy Lebeau
@rlebeau
@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.
Remy Lebeau
@rlebeau
@icegood why are you making Indy wait 20s before letting it call SSL_connect()? Maybe you are encountering an error due to the default 30s timeout assigned by TIdSSLIOHandlerSocketOpenSSL.OpenEncodedConnection()