Skip to content
This repository was archived by the owner on Aug 4, 2023. It is now read-only.

Conversation

watson
Copy link
Contributor

@watson watson commented Nov 12, 2018

If the server responds before the client have ended the request, it means something didn't go as planned and the server have given up trying to process the request. It therefore doesn't serve any purpose to continue sending data to the server in that request and we should abort.

@watson watson self-assigned this Nov 12, 2018
@watson watson requested a review from Qard November 12, 2018 09:54
@watson watson force-pushed the abort branch 3 times, most recently from 021e57b to 5873547 Compare November 12, 2018 11:04
If the server responds before the client have ended the request, it
means something didn't go as planned and the server have given up trying
to process the request. It therefore doesn't serve any purpose to
continue sending data to the server in that request and we should abort.
@watson watson merged commit 73d2b09 into elastic:master Nov 13, 2018
@watson watson deleted the abort branch November 13, 2018 00:18
trentm added a commit to trentm/apm-nodejs-http-client that referenced this pull request Mar 11, 2021
- fix 'assert' usage for node 8.6
- always destroy the intakeReq on error, I observed (in node 8.6 at
  least) a intakeReq "timeout" after both a "close" and "error" event.
  I guess those don't clear the socket timeout. I'm not sure if this is
  tied to keep-alive agent. In any case, if there is an error, let's
  make sure to recycle that socket.
- gzipStream.pause() on premature response from APM server just in the
  rare/unlikely case reading the response body and destroying takes
  a long while. This is a nod to
  elastic#32
  but I'm not sure it is necessary. Doesn't hurt.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants