[
https://issues.apache.org/jira/browse/KNOX-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967425#comment-16967425
]
James Chen commented on KNOX-2095:
----------------------------------
I managed to create a test case and have ant verify pass for the repository;
unfortunately, I'm a bit new to Apache's Gitbox setup and am not entirely sure
how to set up an account. Still looking into it, but I'd guess I don't have
committer access based on
[https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-1.Checkoutsourcecode].
Accordingly, I've created a new patch corresponding to my commits at KNOX-2095
in the attachments. I don't see any obvious way to set up a PR; is setting up a
patch the right way to go about this?
> 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.4.0
>
> Attachments: KNOX-2095.patch, jamchen504patch.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> 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)
