You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of the problem including expected versus actual behavior:
We have Elasticsearch hosted on a relative path, such as: https://mysite.com/elastic/
When we try to make any search request from the .NET client, we are getting 404 error because the client uses only the base uri: https://mysite.com/
Steps to reproduce:
Set URI of elasticsearch: var uri = new Uri("https://mysite.com/elastic/");
Initialize node pool: var nodePool = new SingleNodePool(uri);
Initialize settings: var settings = new ElasticsearchClientSettings(nodePool, ...);
Initialize client: var client = new ElasticsearchClient(settings);
Make any request, e.g. var info = client.Info();
In the response (via debug information enabled, and via OnRequestCompleted logging) we can see that the requested URL was: GET https://mysite.com/?pretty=true&error_trace=true (/elastic/ path is missing).
Expected behavior
We expect the .NET client not to alter the original elasticsearch URI path provided.
More info
In the old NEST Elastic .NET Client (e.g. v7.15.0) this bug doesn't occur. I found this connected issue, which deals with the very same bug we experience: #3691
I believe the bug is connected to Uri construction, see Microsoft documentation remarks here:
if the relativeUri begins with a slash, then it will replace any relative part of the baseUri
In the NEST v7 client, ApiUrlsLookups class contains all paths without leading slash (thus it won't replace the relative part of the base uri):
However, in the current v8 client, ApiUrlLookup class contains all paths with leading slash (thus it will replace the relative part of the base uri):
The text was updated successfully, but these errors were encountered:
I confirmed this bug is indeed caused by the leading / character. I'll implement a fix in the code generator and make sure it will be included in the next patch release.
Elastic.Clients.Elasticsearch version: 8.9.0
Elasticsearch version: 8.8.1
.NET runtime version: 6.0
Operating system version: Windows 10
Description of the problem including expected versus actual behavior:
We have Elasticsearch hosted on a relative path, such as: https://mysite.com/elastic/
When we try to make any search request from the .NET client, we are getting 404 error because the client uses only the base uri: https://mysite.com/
Steps to reproduce:
var uri = new Uri("https://mysite.com/elastic/");
var nodePool = new SingleNodePool(uri);
var settings = new ElasticsearchClientSettings(nodePool, ...);
var client = new ElasticsearchClient(settings);
var info = client.Info();
In the response (via debug information enabled, and via OnRequestCompleted logging) we can see that the requested URL was: GET https://mysite.com/?pretty=true&error_trace=true (/elastic/ path is missing).
Expected behavior
We expect the .NET client not to alter the original elasticsearch URI path provided.
More info
In the old NEST Elastic .NET Client (e.g. v7.15.0) this bug doesn't occur. I found this connected issue, which deals with the very same bug we experience: #3691
I believe the bug is connected to Uri construction, see Microsoft documentation remarks here:
In the NEST v7 client, ApiUrlsLookups class contains all paths without leading slash (thus it won't replace the relative part of the base uri):
However, in the current v8 client, ApiUrlLookup class contains all paths with leading slash (thus it will replace the relative part of the base uri):
The text was updated successfully, but these errors were encountered: