Race condition in http.ClientRequest causes socket to hang up upon req.write().

[c4milo]

I already described and discussed this issue with @mikeal in #2812. He agreed in that it may be a bug.

[isaacs]

Summary, please correct me if I'm wrong.

Gist: https://gist.github.com/1889610

Problem: Chunks written to a socket which is used by an HTTP request in the on('socket') event will precede the header, resulting in an invalid HTTP request, and (probably) the server killing the connection.

Possible solutions:

1. Document the behavior (somewhat unsatisfying, but 100% safe.)
2. Don't emit socket event in an HTTP request as soon as the socket is assigned, but rather immediately after the headers etc. have been written to it. (Simple safe workaround, but somewhat inelegant. Change to behavior which could break programs. This is not allowed in v0.6, unless we recently changed the behavior from this for some reason, in which case, this would be a bugfix.)
3. Add a second event socketReady or something that will be emitted once the socket is ready for writing (ie, after the headers are written.) New API, not allowed in v0.6.
4. Start all/most streams in a "paused and buffering" state, and only unpause the http stream when the underlying TCP stream is ready to have HTTP body bits written to it. (Most elegant, but most work, and need to tread very carefully to get the performance characteristics right.)

[c4milo]

it summarizes correctly the issue @isaacs. I am also more inclined towards number 2. It's just to make sure that the first req.write() sends the request along with headers and before the socket event is emitted.

[isaacs]

Oh, actually, number 2 might not be an option in v0.6. It would break the optimization we have to send the response in a single packet when you do res.writeHead(200); res.end("bar");.

I'm inclined to just document this wart, and fix it properly in master.

[c4milo]

I am fine having it documented. I'll be also extremely useful to have the events model or state machines documented somewhere, so that people can better understand how modules like net and http interact between each other through those events.

[koichik]

Actually, cause of this is net module not http. I will write the patch soon.

[koichik]

@isaacs Can you review koichik/node@f15885c (for v0.6 branch)?

[c4milo]

boom!, that made it @koichik. Nicely done, it's working fine for me.

[isaacs]

@koichik Looks good to me. Land at will.

[koichik]

@isaacs Thanks, merging.

[koichik]

@c4milo Thanks for the report, fixed in cd5d247 (master) and 6343179 (v0.6).