On 13 April 2012 08:53, Brian <theturtl...@gmail.com> wrote: > As a counterpoint, my boss's boss at my previous job had enabled pipelining > in Firefox through about:config editor because he was trying to improve > performance, and we ended up with bug reports for our app because our J2EE > app didn't respond in order with HTTP/1.1 pipelining. We couldn't reproduce > the problems he was having on his machine no matter what he did. It took us > weeks to figure out that it was because he had pipelining enabled in his > browser.
Ah, sorry, I meant to say that there are no clients I know of that pipeline _upgrade_ requests. Though, good point, I haven't checked if Firefox tries to with that option set. > WebSocket-Node writes the 101 response manually via socket.write(). > https://github.com/Worlize/WebSocket-Node/blob/31c47d1622c6f626235eed3ed516c3d2afe1a91d/lib/WebSocketRequest.js#L223 > > I suppose that's not ideal from an API perspective. You could do > res.writeHead(101) immediately followed by socket.write(), but that probably > wouldn't end up in the same TCP frame if Nagle was disabled. I always assumed that writes end up in a queue somewhere waiting for poll() to tell the socket is writeable, but it looks like that's not true. If I'm following the code correctly, libuv flushes immediately (during the `write()` call) if it can. So then what I saw was probably indeed Nagle's. I suppose it's not a good thing to rely on Nagle's here? -- Stéphan Kochen Two Screen, Angry Bytes
