fphttpclient - ESocketError, time out on localhost ElasticSearch

[LeadGuit]

Hi,

As I'm diving in, I thought I could write a small unit for doing some basic stuff with Elasticsearch.

The Elasticsearch server run on localhost, default port 9200. Curl from win and Linux etc work flawlessly, but fphttpclient seems to struggle a little with the mentioned ESocketError. Other ports work properly. Minimal Code is here:

Code: Pascal  [Select][+][-]

1. unit Elasticsearch;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. procedure testget;
8.  
9. implementation
10.  
11. uses
12.   Classes, SysUtils, opensslsockets, fphttpclient;
13.  
14. procedure testget;
15.   var
16.     S: Rawbytestring;
17.   begin
18.     with TFPHTTPClient.Create(nil) do
19.         s := SimpleGet('http://localhost:9200');
20.     WriteLn(S);
21.     ReadLn;
22.   end;
23.  
24. end.  
25.  

If I e.g. spin up a python httpserver, even on the same port (after stopping Elasticsearch) works nicely. I have no idea why that ESocketError is raised - for all I know, if I curl from the command line with no arguments added, that should be almost identical to the SimpleGet (or Get for that matter) call?

Best,
Mat

[marcov]

Without any detailed investigation:

9 times out of 10, the url has a redirection, and you haven't registered an ondirect(ion) handler.

[LeadGuit]

Thanks,

I set AllowRedirect := True, but that didn't work (same Error as before).

It's hard to find an explanation for the handler you mentioned - the wiki only mentioned the AllowRedirect for that - if you could help me out there?

I'm not sure what fphttpclient does under the hood - both linux and Windows curl and browsers display the default JSON right away. If I can trust the DevTab in Chrome, it's a straight call. from wget

Code: Bash  [Select][+][-]

1. Resolving localhost (localhost)... 127.0.0.1
2. Connecting to localhost (localhost)|127.0.0.1|:9200... connected.
3. HTTP request sent, awaiting response... 200 OK
4. Length: 536 [application/json]
5. ....
6.  

[Gustavo 'Gus' Carreno]

Hey LeadGuit,

Could you please provide us with your FPC version please?

There's been a mounting number of posts on the forum due to issues that arose from the update from FPC 3.0.4 to 3.2.0, and SSL, in terms of fphttpclient.
Some, if not most, are problems with SSL. Which is not completely the case here.
I've solved most of the version and SSL issues on the example project attached.

Have a test drive and see if the errors is still present. If so, then you have a problem particular to your installation that needs to be drilled down.

Cheers,
Gus

[trev]

Without any detailed investigation:

9 times out of 10, the url has a redirection, and you haven't registered an ondirect(ion) handler.

The other 1 out of 10 the issue is the user agent being used. Does ElasticSearch check user agents?

[LeadGuit]

Hey LeadGuit,

Could you please provide us with your FPC version please?

Stable, 3.2.0

There's been a mounting number of posts on the forum due to issues that arose from the update from FPC 3.0.4 to 3.2.0, and SSL, in terms of fphttpclient.
Some, if not most, are problems with SSL. Which is not completely the case here.
I've solved most of the version and SSL issues on the example project attached.

Have a test drive and see if the errors is still present. If so, then you have a problem particular to your installation that needs to be drilled down.

Cheers,
Gus

The sample project works flawlessly. As said, other things work well too, it only concerns Elasticsearch.
I tested it with my "production" instance, which lies on another server behind a VPN, and that works as well. Both my local one and the production operate without SSL.

So my  guess is that there is a special constellation that troubles FPC. To elaborate - essentially what I'm doing is running a WSL2 (Windows Subsystem for Linux) on my Win 10. I use the Linux VM for all my dayjob development, so e.g. Elasticsearch is also installed on there. The development in Lazarus takes places on Windows (WSL is only CLI, or GUI via an installed XServer on windows). Could it be that fphttpclient goes "another way" contrary to curl et al? The ES installation is relatively Vanilla. Other thing served from the Linux part are "gettable", on various ports. Just ES is a little reluctant, and only with FP.
E.g. my usual Python scripts on the linux machine work as expected, and a Chrome-Plugin to voew ES Data (on Windows) also connects without issue, curl on the linux subsystem as well as on windows are able to fire the get request.

The other 1 out of 10 the issue is the user agent being used. Does ElasticSearch check user agents?

Not that I know, no - ES mainly offers an API for programmatic consume. The test with my production instance shows that it should work out of the box.

[engkin]

FYI, your usage in the first post is wrong. SimpleGet is a "class method" it does not need an instance, nor does it take any changes you make to the instance you create. Use Get instead.

My guess your problem might be an antivirus or firewall.

[Gustavo 'Gus' Carreno]

Hey LeadGuit,

The sample project works flawlessly. As said, other things work well too, it only concerns Elasticsearch.

Just one more spot of curiosity: Did you point my sample project at your ES instance?
I'm sorry to ask this, but it's not clear from your answer if you did? Either that or I'm very thick

Cheers,
Gus

[LeadGuit]

Hey LeadGuit,

The sample project works flawlessly. As said, other things work well too, it only concerns Elasticsearch.

Just one more spot of curiosity: Did you point my sample project at your ES instance?
I'm sorry to ask this, but it's not clear from your answer if you did? Either that or I'm very thick

Cheers,
Gus

Oh, whoops - I'm sorry. No, I didn't - I just ran it - I thought it would be just to check if connections work. I changed one line to the ES address and the same error occurs:
"Project DownloadProgressBar raised Exception class 'ESocketError' with message:
Connection to localhost:9200 timed out.

At address 100180718"
On Break, it shows me line 165 of the Sequential unit (http.HTTPMethod('HEAD......)

[Gustavo 'Gus' Carreno]

Hey LeadGuit,

Oh, whoops - I'm sorry. No, I didn't - I just ran it - I thought it would be just to check if connections work. I changed one line to the ES address and the same error occurs:
"Project DownloadProgressBar raised Exception class 'ESocketError' with message:
Connection to localhost:9200 timed out.

At address 100180718"
On Break, it shows me line 165 of the Sequential unit (http.HTTPMethod('HEAD......)

Yeap, that kinda makes it officially rather fishy!!

There is absolutely something rather strange with that connection.

Tell me LeadGuit, do you have experience with netcat(nc) and/or the verbose side of cURL?

Is it that the server is serving data in chunked instead of normal and that fphttpclient doesn't grok that? This just occurred to me...
I need to investigate if fphttpclient can manage chunked or even HTTP/2.0

Can you investigate what version of HTTP(1.0 or 1.1 or 2.0, plain, chunked or gzip'ed) is the ES server using and report back, please? Thanks!!

Cheers,
Gus

[LeadGuit]

Yeah - the funny thing is, that the ES version on another server works. Potentially a "breaking" change between versions could be a culprit too:
Server that works: ES 6.8.11
Localhost: ES 7.10.2

Curl-wise, the headers are pretty identical:

Code: Bash  [Select][+][-]

1. *   Trying 127.0.0.1:9200...
2. * TCP_NODELAY set
3. * Connected to localhost (127.0.0.1) port 9200 (#0)
4. > GET / HTTP/1.1
5. > Host: localhost:9200
6. > User-Agent: curl/7.68.0
7. > Accept: */*
8. >
9. * Mark bundle as not supporting multiuse
10. < HTTP/1.1 200 OK
11. < content-type: application/json; charset=UTF-8
12. < content-length: 536
13. <
14. {.....
15. }
16. * Connection #0 to host localhost left intact
17.  

Only differences are the various versions in use (ES itself, lucene etc)

Although I am suspicious of the Windows Hyper-V, where the WSL runs in. Interestingly, a verbose curl from the windows CLI connects to the IPv6:

Code: Bash  [Select][+][-]

1. * Rebuilt URL to: http://localhost:9200/
2. *   Trying ::1...
3. * TCP_NODELAY set
4. * Connected to localhost (::1) port 9200 (#0)
5. > GET / HTTP/1.1
6. > Host: localhost:9200
7. > User-Agent: curl/7.55.1
8. > Accept: */*
9. >
10. < HTTP/1.1 200 OK
11. < content-type: application/json; charset=UTF-8
12. < content-length: 536
13.  

[LeadGuit]

The problem isn't solved per se now - but since ES also isn't supported on WSL, I wasn't able to quickly uninstall it (I'd have to hunt down the directories and remove manually etc).

I installed the 6.8 Version via windows msi, adjusted the Listening address and at least I can access it now, even though, from my dayjob environment on WSL not as localhost. Minor inconvenience.

So, at least you can ease, since it generally works, and WSL (likely due to HyperV Networking or the like) is a kind-of edge case from "dev setup" perspective I think.

[Gustavo 'Gus' Carreno]

Hey LeadGuit,

That is a serious edge case that you stumbled on.
Now the million dollar question is: What side is it from? fphttpclient or ES?

Are you aware of the synapse network library?
It's present on the OPM(No visual components, just put on uses) and you could do some more debugging by it's http client.
And if you feel you have some time to spare, there's also Indy(has visual components for most protocols), another package under the OPM.

These edge cases really intrigue me. And if you stumbled on a reportable bug of the fphttpclient, we maybe need to report it
And if it's not so edge, we might see more people stumbling on it and we need to be aware in order to help or direct somewhere.

Cheers,
Gus

[LeadGuit]

Hey LeadGuit,

That is a serious edge case that you stumbled on.
Now the million dollar question is: What side is it from? fphttpclient or ES?

Are you aware of the synapse network library?
It's present on the OPM(No visual components, just put on uses) and you could do some more debugging by it's http client.
And if you feel you have some time to spare, there's also Indy(has visual components for most protocols), another package under the OPM.

These edge cases really intrigue me. And if you stumbled on a reportable bug of the fphttpclient, we maybe need to report it
And if it's not so edge, we might see more people stumbling on it and we need to be aware in order to help or direct somewhere.

Cheers,
Gus

Definitely intriguing!
I'm extremely new to Pascal and I'm still trying to piece together where to find info on what, as that is a major difference between more "popular" contemporary languages ;-)

I know of synapse and indy (meaning - I know that exists and I likely installed it. I will have a look how they behave with the WSL-Localhost.

[Gustavo 'Gus' Carreno]

Hey LeadGuit,

Definitely intriguing!

You can say that again...

I'm extremely new to Pascal and I'm still trying to piece together where to find info on what, as that is a major difference between more "popular" contemporary languages ;-)

I have this sense that you're a really fast learner!!
And I think you have the strength to persevere!

I know of synapse and indy (meaning - I know that exists and I likely installed it. I will have a look how they behave with the WSL-Localhost.

I would be eternally grateful if you do. Many, many thanks!!

Cheers,
Gus