Hi all.
Currently ClickHouse returns 500 status code for everything it can't execute, be that system error or just invalid query. That goes somewhat contrary to common practices that embrace HTTP spec:
Everything OK? -> 2xx
Dave User has tried to do something he can't be allowed to, because he doesn't have proper auth, specified bad request, provided garbage, referenced missing table? -> 4xx
Specific case of requested entity not existing? -> 404
System error? -> 5xx
While benefits of changing such status codes may not be immediately visible, they do mean much as soon as ClickHouse may be treated as usual HTTP service. Consider following cases:
- Some system updates passwords everywhere, and it needs to validate that new password is working OK. Currently it can't, because 'system crashed' response is indistinguishable from 'invalid authorization'.
- ClickHouse frontend knows that user may enter invalid query, but it, again, can't distinguish 'system error' from 'user input error' and can't mimic ClickHouse parser exactly (especially because different ClickHouse versions would have different functions on board)
Because of that, i think, ClickHouse should eventually implement common system of HTTP status codes that would help end users in automation of any ClickHouse-related tasks they have.
Personally i would go even further with rest/api-versioning approach, but this is 'destroy everything and build from scratch' approach that may be completely not necessary at this moment.
Hi all.
Currently ClickHouse returns 500 status code for everything it can't execute, be that system error or just invalid query. That goes somewhat contrary to common practices that embrace HTTP spec:
Everything OK? -> 2xx
DaveUser has tried to do something he can't be allowed to, because he doesn't have proper auth, specified bad request, provided garbage, referenced missing table? -> 4xxSpecific case of requested entity not existing? -> 404
System error? -> 5xx
While benefits of changing such status codes may not be immediately visible, they do mean much as soon as ClickHouse may be treated as usual HTTP service. Consider following cases:
Because of that, i think, ClickHouse should eventually implement common system of HTTP status codes that would help end users in automation of any ClickHouse-related tasks they have.
Personally i would go even further with rest/api-versioning approach, but this is 'destroy everything and build from scratch' approach that may be completely not necessary at this moment.