[
https://issues.apache.org/jira/browse/THRIFT-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmytro Shteflyuk closed THRIFT-4999.
------------------------------------
Fix Version/s: 0.22.0
Resolution: Fixed
Fix merged in commit
https://github.com/apache/thrift/commit/8ae80a7f8466e5c340388fcb1d797dc3779d9f80
> 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
> Fix For: 0.22.0
>
> Time Spent: 20m
> 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.20.10#820010)
