Angus Robertson

Unless you are processing data at very high speeds or using a very slow platform, which is unlikely with a COM port, a loop is the ideal simple solution to your problem. Just process one character at a time. Angus

I was wrong about this, OpenSSL 1.0.2 included an engine capi.dll which allowed access to private keys in the Windows store and dongles, but not their certificates. It is not currently built for OpenSSL 1,1,1 but may work. There are periodic questions in the OpenSSL mailing list about CAPI, but the original author of the engine is no longer updating it, and CAPI has been replaced by CNG by Microsoft. So there is little evidence the CAPI engine still works. Angus

URL encoding for GET and POST is the same, although POST may accept Json or XML instead. Don't like + for space, should always be %20. The + originates from browser form fields with application/x-www-form-urlencoded MIME POST content, and should not be used in URLs or parameters. Angus

THttpCli does not encode any parameters, you added that coding, so if the URL does not work you need to correct your code as I suggested yesterday. Angus

The server has decided it does not like your parameter encoding, but you don't say you how you do it. Generally, you encode to UTF8 first, then use IcsUrlEncode for each parameter, then combine the parameters. But there are variations on URL encoding, the latest beta has a new strict parameter for Twitter which is very fussy. The better way is to change your application to use TSslHttpRest component, which has RestParams that do all this stuff for you, mostly correctly. . But update to at least V8.64 first, or even the overnight zip, there have been a lot of changes this year. Angus

I've made TriggerSendData virtual in wsocket, most other triggers are already virtual but guess no other component needed to override until now. The change will be in the overnight zip later this week. Angus

THttpsGetFile was probably one of the many Usermade components written 20 years ago and not touched since. But he now has a modern version. TIcsHttpMulti. Angus

As I said, it may use ICS components, but is not part of the ICS distribution. Need to see the source code to know who wrote it and how. For simple file downloads build the OverbyteIcsXferTst.dpr sample and try HTTP Downloads. Angus

THttpsGetFile is not an ICS component. It may be derived from an ICS component, but you need to ask whoever wrote it. Angus

If you really need progress indication, make sure you don't update it more than once a second, certainly not every time the onDocData event is called. Doing so will slow down your transfers due to the overhead of updating the screen control so often. Look at the TIcsHttpMulti.onHttpDataEvent function in OverbyteIcsHttpMulti.pas, which is another new component specifically designed for downloading files, from a list of URLs or by parsing an HTML page, it checks for existing older versions of the files which are updated if newer. The sample is OverbyteIcsXferTst1.dpr. Angus

I used your URL with the OverbyteIcsHttpRestTst sample, and it works perfectly with http/1.1 and Cloudfare and correctly redirects to your executable and downloads it: < Content-Type: application/x-executable < Content-Length: 5286400 You are assuming DocBegin is only called for a successful 200 request, when it is called otherwise. Not sure why you want a download bar, they were useful 20 years ago with slow downloads, or for very large files, but 5MB comes down in a couple of seconds in the modern world. You may want to consider changing to use TSslHttpRest which will simplify your application and make it more robust and future proof, you don't really need any events. Angus

It is unlikely to be related to chunking, this fails before the body is processed. You can not disable chunking at the client, only the server. All I need is the URL that fails, not demos. Angus

Looks like a bug in the ICS relocation code, which is quite complex, messy and hard to maintain, but I will not look at it without being able to reproduce the problem, not interested in logs, although someone else may spot the problem from them. Angus

The most common reason for altering HttpPror.pas was to add extra HTTP headers that the early versions did not support directly, although they could be added using events. Typically authentication headers. But a lot has changed over the years, there are many new authentication methods supported and a new property ExtraHeaders for unusual headers. Angus

Not sure which certificates you are referring to, HTTPS clients receive certificates from servers, and can check they are legitimate, but can accept them anyway. In rare high security cases HTTPS clients have a certificate to prove their identity issued by a company they want to access, mostly VPNs, but any you had 13 years ago will be useless now. Angus