Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 25 13:12
    Coldzer0 closed #332
  • Jan 22 00:52
    rlebeau milestoned #333
  • Jan 22 00:52
    rlebeau labeled #333
  • Jan 22 00:52
    rlebeau opened #333
  • Jan 22 00:52
    rlebeau assigned #333
  • Jan 21 21:30
    rlebeau commented #245
  • Jan 21 21:30
    rlebeau commented #245
  • Jan 20 19:44
    xjikka commented #299
  • Jan 20 18:08
    rlebeau commented #332
  • Jan 20 10:12
    mezen commented #299
  • Jan 20 06:44
    Coldzer0 opened #332
  • Jan 19 17:29
    rlebeau commented #331
  • Jan 19 17:29
    rlebeau commented #331
  • Jan 19 17:22
    rlebeau commented #331
  • Jan 19 17:22
    rlebeau commented #331
  • Jan 18 09:39
    Memnarch edited #331
  • Jan 18 09:39
    Memnarch opened #331
  • Jan 13 11:55
    nag944 commented #299
  • Jan 13 11:54
    nag944 commented #299
  • Jan 13 11:50
    mitzix commented #299
Remy Lebeau
@rlebeau
@lbehm I'm fairly certain that the C++ RTL can't be recompiled by end users, but I have never tried it myself. You will have to ask Embarcadero about that
@BobPlant87_twitter the code that @mezen showed looks fine. It has been a long time since I last tried to connect to Yahoo IMAP with Indy, but I know it did work at one time. The malloc failure is very supicious, you are going to have to ask the OpenSSL community about that one. Which version of the OpenSSL DLLs are you using, and where did you obtain them from?
Bob Plant
@BobPlant87_twitter
@rlebeau I use OpenSSL DLL that comes with Delphi XE 10.2
Bob Plant
@BobPlant87_twitter
1.0.1e
Remy Lebeau
@rlebeau
@BobPlant87_twitter the IDE did not come with OpenSSL DLLs, and besides, 1.0.1 is a VERY old version of OpenSSL (it was EOL'ed back in 2016). You should be using 1.0.2 instead (the last version released before its recent EOL was 1.0.2u), which you can download from here: https://github.com/IndySockets/OpenSSL-Binaries. If you want to use OpenSSL 1.1.x, you will have to use a new IOHandler that is currently under development here: IndySockets/Indy#299. Upgrading to 1.0.2 should solve your issue
Bob Plant
@BobPlant87_twitter
@rlebeau thank you! I'll try that. By the way, is there any manual that describes steps on how to make Indy use static OpenSSL?
Remy Lebeau
@rlebeau
@BobPlant87_twitter Indy supports using OpenSSL statically only on one platform, iOS (see https://blogs.embarcadero.com/openssl-and-https-support-for-ios-devices/ and https://blog.marcocantu.com/blog/using_ssl_delphi_ios.html), the code would have to be updated to allow static usage on other platforms. That has been requested a few times, but no work has been done on it yet (IndySockets/Indy#104). In theory, you should be able to just update one unit for that, IdSSLOpenSSLHeaders_static.pas, to refer to the necessary static lib file(s) and symbols per platform as needed.
mezen
@mezen

When I debug I get EOF, when I don't debug - I get malloc error.

Probably the server sends an EOF during debugging because timeouts were reached during debugging.

Indy supports using OpenSSL statically only on one platform, iOS

Upps, I didnt know that. #299 checks for STATICLOAD_OPENSSL and uses external CLibCrypto; (in the subfolder static) in that case

Remy Lebeau
@rlebeau
@mezen if the new SSLIOHandler supports other platforms, great. The default SSLIOHandler does not, but probably could if IdSSLOpenSSLHeaders_static.pas were updated to handle static object files on more platforms than just iOS. The only reason iOS is handled at all is because at the time that code was written, Apple did not allow OpenSSL to be used dynamically on iPhone/iPad devices (well, just about any dylibs in general), but I think they have since loosened that restriction, but I'm not sure. I don't develop for iOS.
Kudzu
@czhower
@rlebeau Just checking on TLS 1.3 etc.. Im guessing still we arent able to make any headway on those because of the massive chagnes needed in the APIs?
Remy Lebeau
@rlebeau
@czhower TLS 1.3 is being handled by OpenSSL 1.1.x in IndySockets/Indy#299, which is still being tweaked and fine tuned, and has not been merged into the main codebase yet
Kudzu
@czhower
oh cool! Thats awesome news!
how are you faring in 2020?
Remy Lebeau
@rlebeau
@czhower ugg, it has been a pretty lousy year
Kudzu
@czhower
Same here. Lousy might be a bit optimistic in fact for me as an adjective.
glamenoise
@glamenoise
I am using TIdHTTP with custom headers. Testing request to an Abyss server works. Same code sending request to IIS server, the custom headers are dropped. Any ideas?
Remy Lebeau
@rlebeau
@glamenoise can you be more specific? What exactly is being "dropped"? TIdHTTP does not ignore custom headers. How are you setting them?
Asbjørn Heid
@aheid_gitlab
@glamenoise i'm using TIdHTTP against Azure APIs (Azure AD etc) which I presume is IIS, with lots of various custom headers, they all work as expected... are you sure you're talking directly to the IIS server and there's no (reverse) proxy inbetween?
glamenoise
@glamenoise
You might be right. After further research it would seem that this particular website configuration is causing the problem, not an Indy problem.
Asbjørn Heid
@aheid_gitlab
kinda thinking out loud here... if i have a simple http server, which serves simple GET and POST requests, i should be able to write a proxy using indy, with a TIdHTTPServer and simply forwarding the requests using a TIdHTTP in the OnGet... event? (this will be serving typically one request at a time, so absolute performance is not an issue)
Remy Lebeau
@rlebeau
@aheid_gitlab yes, you can do that, though Indy does have a TIdHTTPProxyServer that you might consider looking at, too.
Asbjørn Heid
@aheid_gitlab
@rlebeau thanks again, that does sound useful... i assume i can use the usual SSL IO handler with that so yeah i'll check that out
John
@JEisenheim_twitter
Hi, why is the //BGO:TODO procedure Synchronize(Method: TMethod); overload; line is commented in the IdThread unit? I would like to have access to this procedure. Thank you.
Remy Lebeau
@rlebeau
@JEisenheim_twitter TIdThread derives from TThread, which already has public Synchronize() methods. And TIdThread has a public Synchronize() of its own, which calls the inherited protected TThread.Synchronize(). So, what exactly do you need access to that isn't already accessible? The TODO comment is simply for a TMethod overload of Synchronize(), which is really not necessary in leiu of the TThreadMethod and TThreadProcedure overloads, so I don't know why that comment even exists. Probably a left over from many years ago when TThread.Synchronize() wasn't public yet, and even then Indy had TIdSync to work around that, which is now deprecated in favor of the public TThread.Synchronize()
John
@JEisenheim_twitter
i actually wanted to access the protected Synchronize(AThreadProc: TThreadProcedure), but yes TThread has a public class method for this and I can use that The comment confused me a bit. BTW then why you do have the Synchronize(Method: TThreadMethod) here in IdThread? Can you add the TThreadProcedure version too?
Remy Lebeau
@rlebeau
@JEisenheim_twitter the public TIdThread.Synchronize() instance method exists because it pre-dates the public TThread.Synchronize() class methods (same with TIdSync).
Remy Lebeau
@rlebeau
@JEisenheim_twitter I have just now added a TIdThread.Synchronize() overload for TThreadProcedure
John
@JEisenheim_twitter
@rlebeau Thank you!
kabiri
@kabiri

i use idhttp.get('https: ....
and save answer to stream
and response is :
‹j„èÿí\kOK“þ+ÈŽv% U]]}AŠVæ’l€—ps²g5ê™î±'Øcã ŽòßWƒ±'†÷¼V +ùýâË”Ç.×ÓOW×Ó5óWÍ»¡«mýU B?>ß IÞm·»ßãÛ¬;*‡µ-´j½Ös͐eލ†–$e¸&ñhmkØ…õZ(}’úƒn¿¶U;>·í/Ï¿¾ÿ< ﻽‹/ôu÷X.Z¯ps’v¿îàm¶ûñîìâðàóÝÇâóYÆÇ燍ƒ½sñõ¢ÕÉ:ÃÏéŐØ»;;;|

when i open URL in IE response is true valuse

Remy Lebeau
@rlebeau
@kabiri you would have to show your actual code to be sure, but this typically happens when someone manually configures TIdHTTP to tell the server that the response is allowed to be compressed, but TIdHTTP is not set to actually handle decompression, so the response would have to be decompressed manually. Are you, by chance, setting the TIdHTTP.Request.AcceptEncoding property but not the TIdHTTP.Compressor property? What is the value of the TIdHTTP.Response.ContentEncoding property when the response arrives?
kabiri
@kabiri
@rlebeau idHTTP.Response.ContentEncoding is gzip and i don`t use TIdHTTP.Compressor , how use TIdHTTP.Compressor?
Remy Lebeau
@rlebeau
@kabiri "idHTTP.Response.ContentEncoding is gzip" - then the response is, in fact, compressed. Since you did not set the TIdHTTP.Compressor, the only way that could happen is if you had specified gzip in TIdHTTP.Request.AcceptEncoding. Get rid of that, and the response will not be compressed anymore. DO NOT set the AcceptEncoding manually unless you are prepared to manually handle the encoding(s) you specify, which you clearly are not in this case. So let TIdHTTP manage the AcceptEncoding for you. Had you setup the Compressor, TIdHTTP would have specified gzip for you only if the Compressor was actually ready to handle gzip.
Remy Lebeau
@rlebeau
@kabiri as for the Compressor itself, simply assign it a TIdZLibCompressorBase-derived component, such as TIdCompressorZLib. Its IsReady property will report whether the zlib library is available for use or not. On Windows, Indy uses the zlib library via static-linked .obj files, while on other platforms it uses zlib via an external DLL/dylib instead.
kabiri
@kabiri
@rlebeau i remove this line : idHTTP.Request.AcceptEncoding := 'gzip, deflate, br';
but response not change and idHTTP.Response.ContentEncoding is gzip (again) , i use TIdCompressorZLib and like this IdCZLib := TIdCompressorZLib.Create(nil); idHTTP.Compressor:=IdCZLib; but response not change.
Remy Lebeau
@rlebeau
@kabiri that is because now you are actually prepared to decompress the response. When TIdHTTP sees the Compressor is ready, it will internally set AcceptEncoding := 'deflate, gzip' to enable the response to use compression, and will then decompress the response for you if it is actually compressed. The output stream will receive the decompressed data.
jongruk aripoo
@xchinjo

Could not load SSL library.

CentOS
/usr/lib64/libssl.so
/usr/lib64/libcrypto.so

already compatible linux?

Remy Lebeau
@rlebeau
@xchinjo What error does Indy's WhichFailedToLoad() function report when OpenSSL fails to load? What version of OpenSSL are those .so files actually using exactly? If 1.1.x, they won't work with TIdSSLIOHandlerSocketOpenSSL at all, you would need to use the new SSLIOHandler that is being developed for IndySockets/Indy#299 instead.
SlMaker
@SlMaker
Hey Remy, how to let TIdHTTP use the correct encoding? The RawHeaders of the Response say "Content-Type: text/html;charset=UTF-8"but printing the content shows ? instead of the wanted char ä for FPC. Delphi instead does show the correct character.
Calling Get with IndyTextEncoding_UTF8 fixes the issue but I think this only works if the content is UTF-8 and not something else...
Remy Lebeau
@rlebeau
@SlMaker This is working as designed. FPC still uses string=AnsiString by default (it has a compiler switch to use string=UnicodeString instead, but the RTL largely does not support that yet). Delphi 2009+ uses string=UnicodeString exclusively. TIdHTTP detects the Content-Type charset and decodes the HTTP data to Unicode accordingly, and upon exiting back to user code, that Unicode gets converted to a string. For FPC (and pre-D2009), that means the Unicode is converted to an 8bit AnsiString. By default, the encoding used for Indy's Unicode -> AnsiString conversions is specified by Indy's IdGlobal.GIdDefaultTextEncoding variable, which is set to encASCII by default (for legacy reasons). That is why you are seeing the data loss, and why explicitly telling TIdHTTP to output a UTF-8 encoded AnsiString works. You can set GIdDefaultTextEncoding to encUTF8 if you want to (just know it will affect Indy globally), or you can set the encoding on the TIdHTTP.Get() call itself, as you have already found. Indy is flexible that way. For instance, under Lazarus, the LazUnits package sets apps to use UTF-8 encoded AnsiStrings, so you could detect that condition and set GIdDefaultTextEncoding=encUTF8 to match. And yes, the encoding you specify CAN be different than the encoding used for the original HTTP data, since there are 2 separate conversions involved: HTTPEncoding -> Unicode -> UserEncoding. The ADestEncoding parameter of TIdHTTP.Get() specifies the encoding of the 2nd conversion, the encoding used to decode the source data on the 1st conversion is dicated by the HTTP Content-Type header.
kabiri
@kabiri
@rlebeau I still have a problem and the answer is not decompressed
Remy Lebeau
@rlebeau
@kabiri I would have to see your latest code and the raw HTTP request/response
kabiri
@kabiri

@rlebeau
X:='query_hash=d04b0a864b4b54837c0d870b0e77e076';
X:=X+'&variables={"id":"'+userid+'","include_reel":true,"fetch_mutual":false,"first":24}';
X:=TIdURI.URLEncode('https://www.instagram.com/graphql/query/?'+X);

AResponseContent:=TMemoryStream.Create;

lHTTP.Request.ContentType := 'application/json';

lHTTP.Get(X,AResponseContent);
ShowMessage(lHTTP.Response.ContentEncoding);
AResponseContent.Position:=0;
SetString(buf, PChar(AResponseContent.Memory), AResponseContent.Size div SizeOf(Char));

Remy Lebeau
@rlebeau
@kabiri first off, I would not use TIdURI.URLEncode() is this manner, I would use TIdURI.ParamsEncode() instead, on just the parts that actually need to be encoded (ie don't encode the whole URL as a whole). But more importantly, why are you reading raw data into a TMemoryStream and then copying it as-is into a String, rather than just using the version of TIdHTTP.Get() that returns a String and letting TIdHTTP decode the data properly?
Remy Lebeau
@rlebeau
@kabiri in any case, I need to see the actual HTTP request and response, not just your code (are you still setting up a Comrpessor? Is Compressor.IsReady true before calling TIdHTTP.Get()?)
kabiri
@kabiri
@rlebeau Thanks, i change lHTTP.Get(X,AResponseContent); to Reply:=lHTTP.Get(X);
and problem solved , You helped a lot.
karthikgk2004
@karthikgk2004
hi i use indy 10 in delphi 10 it support tls 1.0 only.. how i can update or download latest version of indy
@rlebeau where i can get Indy 10 latest version
kabiri
@kabiri
@rlebeau I used TMemoryStream because I wanted to save the answer in a file
Remy Lebeau
@rlebeau
@karthikgk2004 Indy 10 supports TLS v1.0 - v1.2 via OpenSSL up to 1.0.2u (support for TLS v1.3 via OpenSSL v1.1+ is still experimental, see IndySockets/Indy#299). You can get the latest snapshot of Indy from its GitHub repo (https://github.com/IndySockets/Indy/).