You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "Larry McCay (Jira)" <ji...@apache.org> on 2020/03/26 23:52:01 UTC
[jira] [Updated] (KNOX-2095) Many errors (E.G. 504s) being masked
as 500 errors
[ https://issues.apache.org/jira/browse/KNOX-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Larry McCay updated KNOX-2095:
------------------------------
Fix Version/s: (was: 1.4.0)
1.5.0
> Many errors (E.G. 504s) being masked as 500 errors
> --------------------------------------------------
>
> Key: KNOX-2095
> URL: https://issues.apache.org/jira/browse/KNOX-2095
> Project: Apache Knox
> Issue Type: Improvement
> Affects Versions: 1.2.0, 1.3.0
> Reporter: James Chen
> Assignee: James Chen
> Priority: Minor
> Labels: easyfix
> Fix For: 1.5.0
>
> Attachments: KNOX-2095.patch, jamchen504patch.patch
>
> Original Estimate: 168h
> Time Spent: 2h 40m
> Remaining Estimate: 165h 20m
>
> When errors occur while accessing the Knox gateway, errors are forcibly overridden and represented as 500 errors, rather than whatever errors they should be.
> For example, when the timeout value under gateway.httpclient.socketTimeout is set to a very low timeout value (E.G. 1 ms) under gateway-site.xml, a socket timeout exception is produced by the getHttpClient().execute( outboundRequest) call. However, this is caught by the surrounding try-catch block and thrown again as an IOException. This results in a generic 500 error, rather than a 504 error one would normally expect from this sort of interaction.
>
> For these sorts of scenarios, I believe it would be prudent to create a dummy HttpResponse using a HttpResponseFactory object for the inboundResponse with the corresponding error code (E.G. HttpStatus.SC_GATEWAY_TIMEOUT in the event of a SocketTimeoutException) and return that instead to trigger the appropriate 504 error. I suspect there are other sorts of potential error code triggers that get this same IOException treatment that would be better off receiving their own error codes.
>
> Judging from the source code, this issue likely affects version 1.3.0, though this has not been tested.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)