Some servers break sometimes with BrokenPipe

[jpic]

This is a follow-up of yourlabs/django-autocomplete-light#284.

@brycenesbitt reported that his server (which we just know has Django and nginx but we don't know which versions, os version, python version, and what wsgi backend version was used) sometimes (reported "about 1 in 50 requests") broke (only a partial traceback was provided) which caused his custom error handler to do an alert.

Please see the initial issue in case I missed a detail, any clue would be helpful.

[dsanders11]

I see this as well, at least in development.

The broken pipe is definitely a result of the aborting the XHR. Removing this from the code gets rid of the broken pipes.

In Google Chrome, at least, aborting the XHR also breaks any benefit from connection keep alive. With HTTPS enabled servers this adds an extra 100+ ms to start HTTPS on the new connection.

Can the use of abort be abandoned? Seems like there are two reasons to abort the XHR: 1) to avoid sending it to the server if possible, 2) to avoid confusing the responses.

Most of the time it is going to be sent to the server regardless, which means the server processes it (and gets a broken pipe) even if abort is called. In the unlikely but possible situation where abort is called before the XHR is sent, abort could be used in that specific case using the readystate variable.

For not getting confused about responses from the server, there is already a check in fetchComplete for this.xhr === jqXHR, it seems that adding an else clause which immediately returns (avoiding showing the response) would prevent any confusion and only show the response from the most recent XHR.

[blueyed]

@dsanders11
Makes sense for me!
Do you like to provide a PR for this?