Shira

Nevermind that, I had some conflict with another package where a component is using TWSocket, I worked around it then it installed fine.

Edited

I haven't been able to install the new release under Delphi 11, either the 8.70 or the daily snapshots, always getting this error about OverbyteIcsHtmlPars, installing the VclFmx group: if I try the VCL-only group, only a few components get installed:

That url is just an example, another exe my app downloads is around 70MB, not everyone has fiber optic. As you say 1.1 works fine, the problem is the double DocBegin trigger, shouldn't it happen only when the actual file starts?

That's correct, but the underlying issue comes from DocBegin triggering inbetween the 302 before the redirection starts, which I don't think it should. Please note I'm not asking for help, criticizing or demanding a fix in any way, I just found what I deemed to be a possible bug so I reported on it for discussion. I have been using your ICS suite for around 20 years and love it 🙂

I found that when this triggers, AMax = -1 procedure TProgressBar.SetParams(AMin, AMax: Integer); begin if AMax < AMin then raise EInvalidOperation.CreateFmt(SPropertyOutOfRange, [Self.Classname]);

Disabling GZip (httpoEnableContentCoding) produces the same results. How do you disable chunk encoding in HttpCli?

Further testing, encapsulating that line with Try Except ... makes it work, and does not trigger an exception Try ProgressBar1.Max := HttpCli1.ContentLength; Except On E:Exception do begin Memo1.Clear; Memo1.Lines.Add(E.Message); end; End; but running the app with the debugger on (F9) does trigger here: procedure TProgressBar.SetParams(AMin, AMax: Integer); begin if AMax < AMin then raise EInvalidOperation.CreateFmt(SPropertyOutOfRange, [Self.Classname]); with "TProgressBar property out of range" In both 1.0 and 1.1 cases the ContentLength property has the same value when DocBegin triggers.

After further debugging it gets even stranger: I found this code is causing the 404, so I thought probably the SendMessage in TProgressBar.SetParams is causing this due to the way WSocket works with messages, similar to how Application.ProcessMessages can cause these issues. procedure TForm1.HttpCli1DocBegin(Sender: TObject); begin ProgressBar1.Max := HttpCli1.ContentLength; end; but then this simple change fixes it' procedure TForm1.HttpCli1DocBegin(Sender: TObject); begin ProgressBar1.Max := HttpCli1.ContentLength + 1; end; this also works ProgressBar1.Max := 1; ProgressBar1.Max := ProgressBar1.Max + HttpCli1.ContentLength; but this fails... ProgressBar1.Max := HttpCli1.ContentLength; ProgressBar1.Max := ProgressBar1.Max + 1; but then.. directly setting a random value works: ProgressBar1.Max := 123; which kinda invalidates the problem being related to the ProgressBar SendMessage. The main factors still remain through all this, HTTP/1.0 works in all cases, HTTP/1.1 fails 😵 I can provide a working demo to reproduce this if you need. Edit: using a custom progressbar without SendMessage to set its Max property also works.

EDIT: real issue identified here: Hi, I encountered a weird issue with the THttpCli component: My app downloads a file from my website through a php script that redirects to the actual file. I recently set my website to use CloudFlare and the following happens: - HttpCli set to use HTTP 1.0: works fine both with cloudflare and the original website - HttpCli set to use HTTP 1.1: works fine my website, but when routing through CF it results in a 404 error (HttpCli1.StatusCode on HttpCli1RequestDone), even though the headers return 302 These are the headers returned by CloudFlare (some data removed):

I know, that's why I quoted it, I meant to say the issue is due to how the browser (properly) processes that. I don't know what Imgur is thinking removing the PIN method auth, making life even harder for desktop apps. Now I can only embed a browser window to have the user enter their user/pass (beats the whole purpose of OAuth + other issues) or use an app protocol for the redirection (another set of issues).

Hi, nevermind that, it seems to be an "issue" with the browser: http://localhost:8080/test?aaa=1#bbb=2&ccc=3

Hi, I'm using the WebSrv for Imgur's API and catch the tokens after launching the auth URL, so Imgur redirects to localhost with all the params.. but WebSrv can't catch them all because there is a # Imgur redirection; http://localhost:7710/myapp?state=auth#access_token=....&expires_in= etc then WebSrv's OnSimpWebSrvReq only gets "state=auth" and omits the rest.