Angus Robertson

Yes, paths are meant to be encoded within the path delimiters, not / itself, unless after ? So I did the simple fix of only handling space. About 20 links failed my own tester with full encoding. So a new version is in SVN. That Canadian site also broke the ICS proxy due to not supporting absolute URLs used by proxies, that's been on my list to fix for a year, so got done as well. Testing is always useful, gets me to fix things. Angus

Further to my last comment, I need to change the auto URL encoding for relocation so it does not process a URL that is already encoded correctly. There will be another version soon. Angus

You can check the original location header by keeping it in the onHeaderData event before the relocation actually happens. I'm only auto URL encoding the redirection URL that the user can not change, not a URL passed to the component, that needs careful consideration. Auto URL encoding is effectively what Firefox and Edge/Chrome do. < HTTP/1.1 302 Redirect < Content-Type: text/html; charset=UTF-8 < Location: http://ec.gc.ca/Error 404.html < Content-Length: 153 > GET /Error%20404.html HTTP/1.1 Angus

I found the problem with HEAD and some redirections, it failed to start the redirected request until close was called, a bug that seems to have been there for many years. Looked at my own link checker and I use GET not HEAD which is why I've never seen it. Your 404 error page returns content even for 200 and HEAD. It will be in SVN tonight. Angus

Thanks, change to int_, will be in SVN soon. Angus

I have investigated your URL and fixed it by correcting the bad relocation URL containing a space, at least for GET, but not yet for HEAD so another problem somewhere. In my tests, the server closes the page as soon as a path with a space is found. Testing with Firefox and Edge/Chrome suggests they correct the location path, only Edge displays it corrected. Even after correcting the space the Error 404.html page is returned with a 200 response, despite the page saying HTTP Error 404 - Not Found in English and French, so certainly my link checker would assume the link was okay, I don't parse the page text, maybe you do? This also raises the issue of whether ICS should correct bad URLs, which browsers seem to do. However, such correction is not trivial except for the simplest case of spaces, since we don't want to double encode / for instance. Angus

Bug fixed in SVN, purely cosmetic, did not stop the sample working, Angus

Your Win64 fixes are now in SVN thanks, with a couple more that you missed because they were LongInt. Fortunately most PostMessages already casted pointers correctly, just these older samples. Angus

Sorry, your redirection problem needs actual testing and not had time in the last two weeks for anything new. Angus

I agree that UDP should send whole packets, but when they arrive two or more may be buffered before they are read in the DataAvailable event. Also, they may not be sent as complete packets, for instance a record may be sent in one send/packet then a CRLF as the next send/packet, so if the application is waiting for that CRLF as a record separator, it needs two packets. So best to treat UDP as a stream. Angus

The most important issue about the DataAvailable event is not the size of your Receive/ReceiveFrom buffer, but that you should loop within the event continually reading all waiting data into a larger public receive buffer or stream until Receive/ReceiveFrom returns 0 or less. If you don't do that, the event will be called again immediately you exit it to empty the internal receive buffers. There is no guarantee about the length of data any call to Receive/ReceiveFrom will return even for UDP, it might take several events for a full packet to be assembled, rarely, but it can happen. As I said before, all this is done for you in the OverbyteIcsIpStreamLog component . Angus

Your patches don't work on my working copy, I look for changes manually. The samples were never designed or tested to build on Win64, only the components, although we do test the actively supported samples periodically. Angus

You can use the OverbyteIcsUdpLstn sample to see how to receive UDP data. Your won't have megabytes of data waiting when that event is called, in fact you will never know how much UDP data is being sent since it only arrives one packet at a time. So typically you use ReceiveFrom to receive a maximum of say 4K, and then add that to a large receive buffer. Much easier to use the new OverbyteIcsIpStreamLog component which does all this for you, look at the OverbyteIcsIpStmLogTst sample. Angus

Some of these old samples do illustrate programming techniques or features that the SSL samples don't, and it takes effort to remove old things... Angus

That is a very old sample that does not support SSL/TLS. The current active HTTPS client samples are OverbyteIcsHttpsTst.dpr and OverbyteIcsHttpRestTst.dpr in the sslinternet directory. Angus

The proxy setters changes are now in SVN, with an updated OverbyteIcsSocksTst sample that now also tests HTTP Tunnelling, which we did not seem to do. Will be zipped overnight. I tested the HTTP Tunnelling changes against the ICS proxy server, which currently deliberately only tunnels HTTP, need to fix that, but have not tested socks since 7Proxy failed my 10 minutes to find out how to configure it limit, sure it works fine once you find some non-empty help files. Angus

I added OverbyteIcsDefs.inc last week, not in SVN yet, other stuff pending. But OverbyteIcsTicks64 has always compiled okay, it is in the IcsCommonDxx package which is built weekly, so your problem must be something else. Angus

I've added SetSocks and SetHTTPTunnel to TCustomSocksWSocket, with a new ProxyURL property. Not in SVN yet. I can test HTTP Tunnelling through the ICS Proxy Server I have running on my public servers, but can not find any samples that use it. We do have OverbyteIcsSocksTst, but I don't currently have a SOCKS server running. Less sure about SetURL() which only sets the wsocket host and port, is that really worthwhile? Angus

You need a message handler in the thread execute loop, to handle all the events, these lines are from TMailQuThread.Execute; in OverbyteIcsMailQueue.pas. FIcsWndControl.ProcessMessages ; if FIcsWndControl.Terminated then break ; if NOT FActive then break ; // component if Terminated then break ; // thread if (errorcounter > 10000) then break ; // sanity check Angus

Thanks, seems my local version of the D2007 package with VCLZip has slipped into SVN, will fix that shortly. Always hate updating ICS packages, over 100 units to modify. Angus

Next week... Angus

Url is not a large unit and probably linked into most applications anyway, except the simplest, so it can happen. I've also just saved a lot of space by removing a lot of legacy OpenSSL support code. Angus

Thanks, will have a look next week. BTW, your last proxy fix is in SVN now, seems I broke it adding international domain name support. Angus

ICS is maintained using Delphi 2007, so is the best tested platform, provided I put the correct files in SVN. VCLZlip is controlled by OverbyteVclZip.inc, and the version in my SVN has {.DEFINE Zipping}. TIcsTwitter, etc were added six months ago to OverbyteIcsSslHttpRest.pas, so you probably have an old version somewhere. Angus

That unit does not have the definitions include, but does not use any of them either, and seems to compile fine in all the packages Angus