New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle bad HTTP requests #23153

Merged
merged 11 commits into from Feb 13, 2017

Conversation

Projects
None yet
2 participants
@jasontedor
Member

jasontedor commented Feb 13, 2017

When Netty decodes a bad HTTP request, it marks the decoder result on the HTTP request as a failure, and reroutes the request to GET /bad-request. This either leads to puzzling responses when a bad request is sent to Elasticsearch (if an index named "bad-request" does not exist then it produces an index not found exception and otherwise responds with the index settings for the index named "bad-request"). This commit addresses this by inspecting the decoder result on the HTTP request and dispatching the request to a bad request handler preserving the initial cause of the bad request and providing an error message to the client.

Closes #23034

Handle bad HTTP requests
When Netty decodes a bad HTTP request, it marks the decoder result on
the HTTP request as a failure, and reroutes the request to GET
/bad-request. This either leads to puzzling responses when a bad request
is sent to Elasticsearch (if an index named "bad-request" does not exist
then it produces an index not found exception and otherwise responds
with the index settings for the index named "bad-request"). This commit
addresses this by inspecting the decoder result on the HTTP request and
dispatching the request to a bad request handler preserving the initial
cause of the bad request and providing an error message to the client.

jasontedor added some commits Feb 13, 2017

Log failure to send message
When dispatching a bad request, if sending the response to the client
fails, we should log the bad request cause and the underlying cause of
the failure to send.
Handle unknown cause on bad request dispatch
When a bad request is dispatched, in case the cause is unknown we should
indicate such.

@jasontedor jasontedor requested a review from jaymode Feb 13, 2017

@jaymode

LGTM

void dispatchRequest(RestRequest request, RestChannel channel, ThreadContext threadContext);
/**
* Dispatches the {@link RestRequest} to the bad request handler.

This comment has been minimized.

@jaymode

jaymode Feb 13, 2017

Member

nit: can you make "bad request" more concrete/descriptive or give a example

This comment has been minimized.

@jasontedor

jasontedor Feb 13, 2017

Member

I pushed c617b7e.

jasontedor added some commits Feb 13, 2017

Merge branch 'master' into handle-bad-requests
* master:
  Update to forbiddenapis 2.3 (improves Gradle configuration time) (#23154)
  Make the version of the remote node accessible on a transport channel (#23019)
  Fix total disk bytes returning negative value (#23093)
  Fix communication with 5.3.0 nodes
  Update redirects.asciidoc (#23148)

@jasontedor jasontedor merged commit 5343b87 into elastic:master Feb 13, 2017

1 of 2 checks passed

elasticsearch-ci Build started sha1 is merged.
Details
CLA Commit author is a member of Elasticsearch
Details

jasontedor added a commit that referenced this pull request Feb 14, 2017

Handle bad HTTP requests
When Netty decodes a bad HTTP request, it marks the decoder result on
the HTTP request as a failure, and reroutes the request to GET
/bad-request. This either leads to puzzling responses when a bad request
is sent to Elasticsearch (if an index named "bad-request" does not exist
then it produces an index not found exception and otherwise responds
with the index settings for the index named "bad-request"). This commit
addresses this by inspecting the decoder result on the HTTP request and
dispatching the request to a bad request handler preserving the initial
cause of the bad request and providing an error message to the client.

Relates #23153

jasontedor added a commit that referenced this pull request Feb 14, 2017

Handle bad HTTP requests
When Netty decodes a bad HTTP request, it marks the decoder result on
the HTTP request as a failure, and reroutes the request to GET
/bad-request. This either leads to puzzling responses when a bad request
is sent to Elasticsearch (if an index named "bad-request" does not exist
then it produces an index not found exception and otherwise responds
with the index settings for the index named "bad-request"). This commit
addresses this by inspecting the decoder result on the HTTP request and
dispatching the request to a bad request handler preserving the initial
cause of the bad request and providing an error message to the client.

Relates #23153

@jasontedor jasontedor deleted the jasontedor:handle-bad-requests branch Feb 14, 2017

@jasontedor

This comment has been minimized.

Member

jasontedor commented Feb 14, 2017

Thanks @jaymode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment