Skip to content
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

Enable socket reuse #29

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

mgorczyca
Copy link
Contributor

Existing code checks req.useChunkedEncodingByDefault, which prevents socket reuse for persistent connection.

update my fork from master
Existing code checks req.useChunkedEncodingByDefault, which prevents socket reuse for persistent connection.
@simov
Copy link
Member

simov commented Apr 21, 2015

@mgorczyca the tests in the request module seems to be passing with this fix, however I'm a bit wary about adding fixes without tests. And since this repository doesn't have any, can you add a failing test in the request repository instead? We have a test-agent.js file or something similar there.

@mgorczyca
Copy link
Contributor Author

@simov the error which led to this PR occurred when attempting to use a SOAP https client that required authentication via login. Because the forever-agent code currently does not reuse the socket in the case of https and PUT, the login worked but the authentication did not persist. So, the next command (after login) could not execute.

The simpler test case we have been using is to see that there is only one connect in the strace output after doing two PUTs on an https URL. Seeing two connects in the strace output indicates that the socket is not being reused, but does not result in an error.

Given the context of the issue as described, what are your thoughts on the type of test case that would mesh well with the tests you already have? Thanks!

@mgorczyca
Copy link
Contributor Author

@simov I have added a test for this fix in the request repository, in the test-agent.js file as you suggested.

@robinjmurphy
Copy link

@mgorczyca @simov Is there any reason why useChunkedEncodingByDefault was used over chunkedEncoding originally? This is proving to be an issue for us as we're using Node 0.10.0 and want to avoid costly TLS handshakes for PUT requests.

Happy to add some tests to this module directly for the behaviour if there's no obvious reason to stick with useChunkedEncodingByDefault.

@simov
Copy link
Member

simov commented Sep 23, 2015

@robinjmurphy, sure, feel free to add tests in request, as for why useChunkedEncodingByDefault was used - I have no idea, it's like that from the start. Probably @mikeal could shed some light on that.

@robinjmurphy
Copy link

I started to write a basic test, but on further investigation it looks like req.chunkedEncoding is always equal to false at the point at which it's evaluated. When making a chunked POST request, it's not until the response event fires on the req object that the chunkedEncoding property is set to true.

I think this means that including the && !req.chunkedEncoding has no effect and suggests that the presence of !req.useChunkedEncodingByDefault is simply a means of limiting socket reuse to GET, HEAD, DELETE, OPTIONS and CONNECT requests (see _http_client.js.)

I haven't yet looked at the core pooling code in Node v4, but if keep alive is disabled for POST/PUT requests there, maybe there's a reason for it that we're missing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants