Skip to content

ResponseBodyInBytes is null when the response is not parseable #1909

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
TioLuiso opened this issue Mar 14, 2016 · 5 comments
Closed

ResponseBodyInBytes is null when the response is not parseable #1909

TioLuiso opened this issue Mar 14, 2016 · 5 comments

Comments

@TioLuiso
Copy link

In our scenario, we do not call directly ElasticSearch. We have a Web Load Balancer in the middle to balance the load between Nodes. Plus, we have an Nginx in the same server for security reasons.

Each one of those elements can return a response by themselves, and thus, the response might not be parseable by NEST. I those cases, it's vital for us to have the raw response. In NEST 1.7 we could read it. Now we cannot.

We have DisableDirectStreaming set to true, and we haven't set ThrowExceptions

@TioLuiso
Copy link
Author

Also, if the Status Code of the response is 4XX - 5XX, it will throw the exception, so ResponseBodyInBytes will be null, also

@gmarz
Copy link
Contributor

gmarz commented Mar 14, 2016

Hey @TioLuiso this has already been fixed and will be in the next release (v2.0.5). See #1856 for details.

@gmarz gmarz closed this as completed Mar 14, 2016
@TioLuiso
Copy link
Author

Looks really great. Any idea when 2.0.5 will be out?

@TioLuiso
Copy link
Author

Just a question. With the default HttpConnection implementation, that uses an HttpWebRequest, when it issues the request, if it receives a 4XX - 5XX status code, it will throw a WebException. That will be caught by OnRequestCompleted handler, but a response won't be returned to the caller (other than the exception).

I have tried you HttpConnection-CoreFx, which uses HttpClient instead, will let you handle the responses and the status codes peacefully.

Do you have any plan to:
a) Update the HttpWebRequest based HttpConnection so that it will return a response.
b) Make HttpClient based HttpConnection available for regular .NET framework?

Thanks a lot

@Mpdreamz
Copy link
Member

So by default webexceptions won't bubble out of the client mimicing the behavior of HttpClient.

Using the default WebRequest based HttpConnection if we see a 500 you will get back an invalid response (response.IsValid == false) and response.ApiDetails.Response will have a copy of the response if you disable directstreaming (since #1856).

However if the response is not json or empty we would still throw (something now fixed as per #1913) again something that will make it into 2.0.5 which we'll release today.

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

3 participants