Skip to content

Using the format=json uri parameter with cat api calls fails #4243

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
CraigWh opened this issue Nov 28, 2019 · 3 comments
Closed

Using the format=json uri parameter with cat api calls fails #4243

CraigWh opened this issue Nov 28, 2019 · 3 comments
Assignees

Comments

@CraigWh
Copy link

CraigWh commented Nov 28, 2019

NEST/Elasticsearch.Net version: 7.2.1

Elasticsearch version: 7.2.1

Description of the problem including expected versus actual behavior: Using the Cat.MasterAsync API and specifying the Format="JSON" parameter returns a response object that has the Success flag set to false but has a status code of 200 and the correct response body. Calling the same method in Elasticsearch.Net 6.8 worked as expected.

I am calling the API like this (this.client is of type IElasticLowLevelClient):

await this.client.Cat.MasterAsync<StringResponse>(new CatMasterRequestParameters { Format = "JSON" });

Provide ConnectionSettings (if relevant):
Using a SingleNodeConnectionPool
Specifying DisableAutomaticProxyDetection and DisablePing

Provide DebugInformation (if relevant):

# Audit trail of this API call:
 - [1] BadResponse: Node: http://localhost:9200/ Took: 00:00:00.0312765
# OriginalException: Elasticsearch.Net.ElasticsearchClientException: Request failed to execute. Call: Status code 200 from: GET /_cat/master?format=json
# Request:
<Request stream not captured or already read to completion by serializer. Set DisableDirectStreaming() on ConnectionSettings to force it to be set on the response.>
# Response:
[{\"id\":\"nodeId\",\"host\":\"hostName\",\"ip\":\"ipaddress\",\"node\":\"nodeName\"}]
@russcam russcam self-assigned this Dec 9, 2019
@russcam
Copy link
Contributor

russcam commented Dec 9, 2019

Thanks for reporting @CraigWh. This looks like a bug caused by the strictness of the response MIME type against the MIME type that was requested. We'll look at addressing this

@russcam
Copy link
Contributor

russcam commented Dec 9, 2019

For now, you can set the Content-Type and Accept headers to allow the call to be deemed successful

var response = await client.Cat.MasterAsync<StringResponse>(new CatMasterRequestParameters { 
    RequestConfiguration = new RequestConfiguration 
    {
        ContentType = RequestData.MimeType,
        Accept = RequestData.MimeType
    }
});

To be clear, the call using format=json is also made, but the MIME type checking means that it ends up being marked as unsuccessful.

russcam added a commit that referenced this issue Dec 13, 2019
This commit updates the ApiGenerator to set the Accept HTTP header when the format
header is specified. To determine whether an API call is successful, the Content-Type header
of the response is checked against the Accept header of the request.

The format parameter only really makes sense for the low level client and associated
ElasticsearchResponse<T> types, as the high level client always expects to deserialize
from JSON; any other format will result in an exception at deserialization.

Fixes #4243
@russcam
Copy link
Contributor

russcam commented Dec 13, 2019

I've opened #4269 to address.

Mpdreamz pushed a commit that referenced this issue Dec 17, 2019
* Set Accept header when format set on Cat APIs

This commit updates the ApiGenerator to set the Accept HTTP header when the format
header is specified. To determine whether an API call is successful, the Content-Type header
of the response is checked against the Accept header of the request.

The format parameter only really makes sense for the low level client and associated
ElasticsearchResponse<T> types, as the high level client always expects to deserialize
from JSON; any other format will result in an exception at deserialization.

Fixes #4243

* Addressed PR comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants