This is an improvement to my earlier PR #67. I realised that I had forgotten to include the response headers in the HttpStatusException. While making the change, I decided to also add the protocol, which is the only other field in HttpResponse.
I did not simply embed HttpResponse because HttpResponse.toStrict doesn't change the object type the way HttpEntity.toStrict does. This means that there was no way (that I can find) to make the exception fields accessible without having to provide all the async context.
Finally, this commit changes the Option[HttpEntity.Strict] in the exception type to a Try[HttpEntity.Strict]. This ensures that if an exception occurs while reading the response body, neither the non-200 status code nor this exception are lost.
This is an improvement to my earlier PR #67. I realised that I had forgotten to include the response headers in the
HttpStatusException
. While making the change, I decided to also add the protocol, which is the only other field inHttpResponse
.I did not simply embed
HttpResponse
becauseHttpResponse.toStrict
doesn't change the object type the wayHttpEntity.toStrict
does. This means that there was no way (that I can find) to make the exception fields accessible without having to provide all the async context.Finally, this commit changes the
Option[HttpEntity.Strict]
in the exception type to aTry[HttpEntity.Strict]
. This ensures that if an exception occurs while reading the response body, neither the non-200 status code nor this exception are lost.All unit tests pass.