Angus Robertson

You don't say what response Gmail is providing when you send email Google Gmail accounts have two levels of security, historically they worked with clear authentication under SSL, and one of mine still does. But if you choose a Google prompt to set 'higher' security on your account that means they will only support OAuth2 so the account password is not stored locally or sent in SMTP commands. Instead the password is entered through a browser window. So for the ICS mail queue component, specify authentication as XOAuth2 and the password field will be greyed. When you start the mail queue, a browser window will appear in which you login with the same account as the user name here. Google returns two tokens, one is used to access Gmail and remains valid for a short time, the second refresh token is saved by the sample as the password and can be used in the background to get a new access token without a browser window. The refresh token usually remains valid for months, unless the account details are changed, but if you are sending unattended emails you need some scheme to allow interaction to login again if new tokens are needed. Before OAuth2 will work, you need a Google application account which is explained in notes at the top of OverbyteIcsSslHttpRest.pas. Angus

I thought I fixed all the incompatibilities with Linux, I was certainly able to build packages for V8.65. But I am not planning any further work to actually test it or make ICS work in Linux, unless someone pays me, I have no plans to write any Linux applications myself. So it's up to those that actually want to use ICS with Linux to make it work, I will then update SVN (with complete source files, not patches). Angus

You reported this rare bug by email, and it was fixed in SVN and the overnight zip last week. The counter was only used as a simple flag so was changed to boolean. Angus

Sorry, the internet hosting centre has been suffering a series of DDOS attacks since the weekend, usually only half an hour at a time before they block it, please just keep trying. The servers themselves are fine, I can access them using my internet connection directly to the hosting centre. Angus

I did wonder whether to write a check URL function, but it's not easy, except for space which is illegal in all URLs. Lots of other special characters like /, & and % may be the result of previous encoding, so you don't know whether to encode them again. But open to suggestions for a URL checker. Angus

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