All all HTTP responses to be deserialized #437
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@haacked can you review this? I've got several customers who have been broken by this regression. |
|
|
Looks like the formatting is off, but other than that, feel free to merge it once you fix that up.
devinrader
pushed a commit
that referenced
this pull request
Oct 11, 2013
All all HTTP responses to be deserialized
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Modifies the behavior of
fde15e2
0fe0fa1
9b423a8
which have caused a regression in RestSharp behavior.
These commits limit RestSharp to attempt to deserialize responses only when the 200, 201 and 203 status codes are returned. This is incorrect as virtually every status code allows you to return a message-body. As far as I can tell there are only two that explicitly prohibit it: 204 and 304.
I believe the original intent of these commits was to try to stop RestSharp from attempting deserialization for non-protocol errors (ex: connection timeouts). In most cases, when RestSharp encounters a non-protocol error, it will handle the error and set the ErrorException and ErrorMessage properties allowing you to detect the occurrence of the exception.
This pull request modifies the prior commits to check the ErrorException property in order to determine of deserialization should be attempted, instead of relying on Status Codes.
Tests are included to simulate RestSharp handling a connection timeout and deserialization of an 400 error message-body. If there are other non-protocol error scenarios that should be tested let me know. I also changed one test back to its original code which would have caught this regression.