Linux + Lazarus issues

[Molochnik]

I've made a small test program to test connections with TCP, UDP and HTTP components and found that:

1. The test program works fine with Delphi both on Linux and Windows
2. It works fine with Lazarus on Windows
3. It doesn't work with Lazarus on Linux producing weird behavior.

The program is attached, you can find there a form with "Start server" (TCP, UDP and HTTP) buttons to start servers on the localhost and "Send" buttons to send packets to them, received responses are placed in the memos below. 1) and 2) versions exchange packets as expected, the 3) version cannot accept packets from all three servers and fails due to various reasons, one of them is an "unknown protocol version".

HTTPDemo.zip

[rlebeau]

"unknown protocol version" is not an Indy error message. Offhand, it sounds more like an OpenSSL error message. Which version of OpenSSL are you trying to use, exactly? And did you verify that the correct version is actually being loaded correctly in the FPC+Linux scenario that doesn't work?

The only difference between Indy's Linux support in Delphi vs Lazarus should be the underlying socket API begin used (see the TIdStackVCLPosix class for Delphi and the TIdStackLibc/TIdStackUnix classes for FPC), which has nothing to do with how Indy uses OpenSSL. Other than the socket APIs, most things in Indy should be nearly identical in both compilers.

What you have provided is a lot of code to go through, and I have no way to test/debug it, as I don't have Linux or FPC environments available.

However, one issue I do see in your code is that you are opening the TLS and non-TLS TCP servers on different listening ports, but your TCP client is only connecting to the non-TLS port even if TLS is being used. So, that alone can cause OpenSSL errors if a non-TLS client connects to a TLS server, or vice versa.

[Molochnik]

Hello Remy,
I see that the example was too convoluted so here is a new refined version. It is much more simpler than before but has the same problems with Lazarus under Linux. You almost definitely wont be able to locate an error without Lazarus on Linux, it's very specific. It has nothing to do with SSL (I could not get to test it yet) so I totally removed it. other unnecessary features were removed too. The test program emulates a simple HTTP server and is very simple to use: start any server - send a packet - receive the result - show it. As I said before it works fine on Delphi+Windows, Delphi+Linux and Lazarus+Windows, The only unworkable solution is under Lazarus+Linux.

Ravil
HTTPDemoRefined.zip

[rlebeau]

I see that the example was too convoluted so here is a new refined version. It is much more simpler than before but has the same problems with Lazarus under Linux.

And, what are the problems EXACTLY? All you mentioned earlier was "unknown protocol version", but that shouldn't be a factor anymore since you removed SSL/TLS from the test. Initially, you said "fails due to various reasons", but you didn't say what they actually were.

You almost definitely wont be able to locate an error without Lazarus on Linux, it's very specific.

Since I don't have a Lazarus+Linux setup, you will have to debug it for me, and then I can post a fix once the underlying cause has been identified.

The test program emulates a simple HTTP server and is very simple to use: start any server - send a packet - receive the result - show it.

Some logic issues I see, but which shouldn't cause platform-related issues:

• THttpServer.TCPServerExecute() is not sending a valid HTTP response (no status line), and also is sending a trailing CRLF after the HTML_TEXT which is not included in the Content-Length header, so THttpServer.SendTCPCommand() doesn't read the CRLF. Not that it matters in this test, since SendTCPCommand() disconnects after the response, but it would be a communication mismatch for clients that don't disconnect.

• in THttpServer.SendTCPCommand(), you don't need the TMemoryStream to receive the server's UTF-8 response, you could use Indy's TIdIOHandler.ReadString() method instead, which has parameters for byte count, byte encoding, and string encoding.

• UDP does not guarantee packets arrive in the same order they are sent. So, in THttpServer.SendUDPCommand(), rather than having the UDP server send 2 separate packets for its response, you should have it send only 1 packet. There is no need to send a packet that just contains the length of the next packet, that is redundant. Either put the content length in the same packet as the content, or just omit the content length altogether since the packet size can serve the same purpose.

As I said before it works fine on Delphi+Windows, Delphi+Linux and Lazarus+Windows, The only unworkable solution is under Lazarus+Linux.

And, what exactly IS NOT WORKING in the Lazarus+Linux scenario that DOES work in the other scenarios? Please be more specific.