4 ms·
Agreed with some of the other posters that this isn't a bug. It would be pretty hard for a browser to make this not work. To make it not work, the browser would
by sysexit 12y ago
Agreed with some of the other posters that this isn't a bug. It would be pretty hard for a browser to make this not work. To make it not work, the browser would have to check whether there's data available in the local socket buffer before issuing an HTTP request. On Unix, you could e.g. put the socket in non-blocking mode, issue a read() to read 1 byte, and then see if you're getting an EWOULDBLOCK. If you get data instead of EWOULDBLOCK, then (supposedly) you're in violation of the RFC and therefore the browser might decide to close the connection (what should it do otherwise?)
It just doesn't make a lot of sense doing the above. Especially because there's a fundamental race condition here: there is no way to distinguish between data that's in-flight but not received prior to the browser issuing the request, and data that was generated after the remote peer read the browser's request.
- colanderman 12y agoYou could encounter this behavior (dropping unsolicited responses) multiple "legitimate" ways (all of which suffer from the race condition you mention): reading & writing in separate threads can do it; so can an asynchronous receive mechanism. Erlang TCP connections can be configured for asynchronous receive: any incoming data is delivered as a message to a given process, which usually immediately acts on it. Say this process has not yet sent a request; it's not unreasonable to just drop the incoming data. Of course, I would consider such behavior non-conforming, for the reasons you point out. Time isn't really defined in a TCP stream. Better is to utilize the flow control Erlang provides for asynchronous receive, but this is extra effort so it's plausible a naive implementation would miss this.