malloc failureis 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?
IdSSLOpenSSLHeaders_static.pas, to refer to the necessary static lib file(s) and symbols per platform as needed.
IdSSLOpenSSLHeaders_static.paswere 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.
TThread, which already has public
TIdThreadhas 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
Synchronize(), which is really not necessary in leiu of the
TThreadProcedureoverloads, 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
TIdSyncto work around that, which is now deprecated in favor of the public
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
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
TIdHTTPto tell the server that the response is allowed to be compressed, but
TIdHTTPis not set to actually handle decompression, so the response would have to be decompressed manually. Are you, by chance, setting the
TIdHTTP.Request.AcceptEncodingproperty but not the
TIdHTTP.Compressorproperty? What is the value of the
TIdHTTP.Response.ContentEncodingproperty when the response arrives?
TIdHTTP.Compressor, the only way that could happen is if you had specified
TIdHTTP.Request.AcceptEncoding. Get rid of that, and the response will not be compressed anymore. DO NOT set the
AcceptEncodingmanually unless you are prepared to manually handle the encoding(s) you specify, which you clearly are not in this case. So let
AcceptEncodingfor you. Had you setup the
TIdHTTPwould have specified
gzipfor you only if the
Compressorwas actually ready to handle gzip.
Compressoritself, simply assign it a
TIdZLibCompressorBase-derived component, such as
IsReadyproperty will report whether the zlib library is available for use or not. On Windows, Indy uses the zlib library via static-linked
.objfiles, while on other platforms it uses zlib via an external DLL/dylib instead.
Compressoris 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.
WhichFailedToLoad()function report when OpenSSL fails to load? What version of OpenSSL are those
.sofiles actually using exactly? If 1.1.x, they won't work with
TIdSSLIOHandlerSocketOpenSSLat all, you would need to use the new SSLIOHandler that is being developed for IndySockets/Indy#299 instead.
TIdHTTPuse the correct encoding? The
"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.
IndyTextEncoding_UTF8fixes the issue but I think this only works if the content is UTF-8 and not something else...
string=AnsiStringby default (it has a compiler switch to use
string=UnicodeStringinstead, but the RTL largely does not support that yet). Delphi 2009+ uses
Content-Typecharset 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 -> AnsiStringconversions is specified by Indy's
IdGlobal.GIdDefaultTextEncodingvariable, which is set to
encASCIIby default (for legacy reasons). That is why you are seeing the data loss, and why explicitly telling
TIdHTTPto output a UTF-8 encoded
AnsiStringworks. You can set
encUTF8if 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
LazUnitspackage sets apps to use UTF-8 encoded
AnsiStrings, so you could detect that condition and set
GIdDefaultTextEncoding=encUTF8to 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
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
lHTTP.Request.ContentType := 'application/json';
SetString(buf, PChar(AResponseContent.Memory), AResponseContent.Size div SizeOf(Char));
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
TMemoryStreamand then copying it as-is into a
String, rather than just using the version of
TIdHTTP.Get()that returns a
TIdHTTPdecode the data properly?