| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
I would think that this would be semver major since it changes the timing?
Sorry, something went wrong.
There was a problem hiding this comment.
Can you capitalize and punctuate this comment please?
Sorry, something went wrong.
There was a problem hiding this comment.
Sure. Done.
Sorry, something went wrong.
|
@evanlucas yeah semver major or patch depending on if it is considered a bug fix or not. |
Sorry, something went wrong.
There was a problem hiding this comment.
nit: This is probably over-micro-optimizing, but using this instead of sock inside the callback would avoid allocating a closure every time here.
Sorry, something went wrong.
There was a problem hiding this comment.
It makes sense. Used sock for readability but happy to fix it.
Sorry, something went wrong.
There was a problem hiding this comment.
It doesn't hurt anything, but you don't really need this assertion since the next one would handle this.
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah but if for absurd err is undefined it will be a TypeError (Cannot read property 'message' of undefined) instead of an AssertionError.
Sorry, something went wrong.
There was a problem hiding this comment.
Yea, but it also doesn't really matter.
Sorry, something went wrong.
There was a problem hiding this comment.
@cjihrig I think it's easier to grok but I'm fine with removing it.
Edit: done.
Sorry, something went wrong.
There was a problem hiding this comment.
in the off chance that someone updates this later to an arrow function, the use of this internally may be slightly problematic. Perhaps make it more explicit using sock.setTimeout(msec, emitTimeout); instead?
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
😄 … yeah, if you want to leave it at sock.setTimeout for readability, I’m fine with that, too. ;)
Sorry, something went wrong.
There was a problem hiding this comment.
Restored sock.
Sorry, something went wrong.
There was a problem hiding this comment.
thank you, I appreciate it.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
re: semver-patch or semver-major, It's not clear to me either. Let's see what @nodejs/ctc think... |
Sorry, something went wrong.
|
It might help to know why the old behaviour was bad, and if it was undesirable in all cases? |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for contributing this! Could you please elaborate on why this is better than the current behavior?
Sorry, something went wrong.
|
@lpinca thank you for explanation! I see that we have an inconsistency here indeed. I wonder if we should do it in reverse instead and always set timeout without waiting for connect event? If we'll go the way it is proposed in this PR, http.request().setTimeout() won't be triggered if socket hasn't connected in a reasonable time. Kernel defaults are usually around 1 minute and this may be too much. |
Sorry, something went wrong.
|
@indutny yes it makes sense. I know that some userland modules use an additional timer that is cleared when the response event is emitted to handle cases like the one you are describing. Should I open a new PR to always set the timeout without waiting for the connect event? If so should this one be closed? |
Sorry, something went wrong.
|
@lpinca perhaps, let's see what others from @nodejs/http or @nodejs/ctc think? Thanks! |
Sorry, something went wrong.
|
@indutny I thought again about this and I think it doesn't make sense to change request.setTimeout() to make it set the timeout without waiting the connect event. It seems that in all cases (1, 2) request.setTimeout() explicitly checks if the socket is connected (with the exception of the one this PR deals with) so I guess it's like this by design. The case you are describing is handled by the timeout option of http.request(). That timeout is forwarded to net.createConnection() without waiting for the socket to be connected. |
Sorry, something went wrong.
|
Closing due to lack of forward progress. We can reopen if necessary |
Sorry, something went wrong.
|
I think it still makes sense. If we want to keep the current behavior we should at least update the documentation accordingly. |
Sorry, something went wrong.
|
I am for reopening this. I think it makes sense and I would consider it as a bug fix because it is clearly documented to behave like this PR. |
Sorry, something went wrong.
Fixes a bug that prevented `ClientRequest.prototype.setTimeout()` from working properly when the socket was reused for multiple requests. Fixes: nodejs#16716 Refs: nodejs#8895
Fixes a bug that prevented `ClientRequest.prototype.setTimeout()` from working properly when the socket was reused for multiple requests. Fixes: #16716 Refs: #8895 PR-URL: #16725 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Fixes a bug that prevented `ClientRequest.prototype.setTimeout()` from working properly when the socket was reused for multiple requests. Fixes: nodejs#16716 Refs: nodejs#8895 PR-URL: nodejs#16725 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#25121 Refs: nodejs#8895 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>
| Back | FazBrowse Home | New Git URL |
Checklist
Affected core subsystem(s)
http
Description of change
request.setTimeout() calls socket.setTimeout() as soon as a socket is assigned to the request. This makes the timeout event to be emitted on the request even if the underlying socket never connects.
This commit makes socket.setTimeout() to be called only when the underlying socket is connected.