When an ElasticsearchException is bubbled up to HTTP, there are additional headers being returned.
# curl -X DELETE localhost:9200/test
{"acknowledged":true}
# curl -X PUT localhost:9200/test -v
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9200 (#0)
> PUT /test HTTP/1.1
> Host: localhost:9200
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Content-Length: 21
<
* Connection #0 to host localhost left intact
{"acknowledged":true}
# curl -X PUT localhost:9200/test -v
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9200 (#0)
> PUT /test HTTP/1.1
> Host: localhost:9200
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< es.index: test
< Content-Type: application/json; charset=UTF-8
< Content-Length: 203
<
* Connection #0 to host localhost left intact
{"error":{"root_cause":[{"type":"index_already_exists_exception","reason":"already exists","index":"test"}],"type":"index_already_exists_exception","reason":"already exists","index":"test"},"status":400}If those headers are not needed on HTTP, maybe it does not make any sense to return them? All the information looks available to me in the HTTP response body, but I am possibly missing some cases.
When an
ElasticsearchExceptionis bubbled up to HTTP, there are additional headers being returned.If those headers are not needed on HTTP, maybe it does not make any sense to return them? All the information looks available to me in the HTTP response body, but I am possibly missing some cases.