[
https://issues.apache.org/jira/browse/THRIFT-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregoire Seux updated THRIFT-4999:
----------------------------------
Description:
This issue is similar to THRIFT-4641.
When receiving a non 2xx code, HTTPTransportClient tries to parse response body
instead of raising a clean TransportError.
We observe a Thrift::ProtocolException instead of a Thrift::TransportException
Example:
- request on http://example.org/test returns an 500 response, with an empty
body (or an error page).
- currently ruby code will not read the response code and blindly try to parse
the body
- this action will fail with ProtocolException (which is, I believe, the error
meaning "protocol is not implemented correctly)
In this case, reading the error code sent by the http layer (500) and raising
appropriate exception (TransportException) feels more correct. This bug was
already present in THRIFT-4641 (for the php client). Quoting this other ticket:
{quote}
TCurlClient doesn't check for HTTP status code. Other languages, such as Go and
Java
do check for it. This can lead to potentially wrong exception being thrown:
TProtocolException
instead of TTransportException. To be more precise, TCurlTransport doesn't
error out and
Protocol starts to parse response, which may lead to TProtocolException. For
example, AWS
ALB may return 502 Bad Gateway with HTML as part of payload when there's an
issue with an
upstream. In such case, a client may want to retry but it only makes sense if
there's a transport
exception.
{quote}
was:
This issue is similar to THRIFT-4641.
When receiving a non 2xx code, HTTPTransportClient tries to parse response body
instead of raising a clean TransportError.
We observe a Thrift::ProtocolException instead of a Thrift::TransportException
> HTTPTransportClient doesn't check for HTTP status code
> ------------------------------------------------------
>
> Key: THRIFT-4999
> URL: https://issues.apache.org/jira/browse/THRIFT-4999
> Project: Thrift
> Issue Type: Bug
> Components: Ruby - Library
> Affects Versions: 0.13.0
> Reporter: Gregoire Seux
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This issue is similar to THRIFT-4641.
> When receiving a non 2xx code, HTTPTransportClient tries to parse response
> body instead of raising a clean TransportError.
> We observe a Thrift::ProtocolException instead of a Thrift::TransportException
> Example:
> - request on http://example.org/test returns an 500 response, with an empty
> body (or an error page).
> - currently ruby code will not read the response code and blindly try to
> parse the body
> - this action will fail with ProtocolException (which is, I believe, the
> error meaning "protocol is not implemented correctly)
> In this case, reading the error code sent by the http layer (500) and raising
> appropriate exception (TransportException) feels more correct. This bug was
> already present in THRIFT-4641 (for the php client). Quoting this other
> ticket:
> {quote}
> TCurlClient doesn't check for HTTP status code. Other languages, such as Go
> and Java
> do check for it. This can lead to potentially wrong exception being thrown:
> TProtocolException
> instead of TTransportException. To be more precise, TCurlTransport doesn't
> error out and
> Protocol starts to parse response, which may lead to TProtocolException. For
> example, AWS
> ALB may return 502 Bad Gateway with HTML as part of payload when there's an
> issue with an
> upstream. In such case, a client may want to retry but it only makes sense if
> there's a transport
> exception.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
