I sort of finished a patch for this.
Still testing though.

---
** [bugs:#1445] HTTP pipelining causes singlesocket() algorithm to fail.**
**Status:** open
**Created:** Sun Nov 02, 2014 08:13 PM UTC by Carlo Wood
**Last Updated:** Sun Nov 02, 2014 08:13 PM UTC
**Owner:** nobody
All requests on a pipeline point to the same connectdata struct (per definition, as that contains the send_pipe and recv_pipe lists).
Socket filedescriptors, if any is assigned to the connection, should be active for writing when the send_pipe is non-emtpy and they should be active for reading when the recv pipe is non-empty.
<b>The algorithm in singlesocket() fails to do this correctly. In general because it calls multi->socket_cb without always looking at both pipelines</b>:
1) Sometimes data->easy_conn is NULL. When that happens then there is no access to the connectdata or pipelines - and the function disregards the existance of the pipeline and simply removes all sockets that the current handle isn't using.
2) At the top of the function singlesocket() makes calls to multi->socket_cb (possibly removing sockets from reading or writing) without looking at the pipelines.
---------------------------------------------------------------------------------
EXAMPLE
An example where the latter (2) causes a bug is the following:
Two (or more) handles are in a recv pipe of some connection. The connection breaks. A new connection is created, and the handle is moved to its send pipe. At this point it is of course the only handle for that connection.
Before this connection succeeds, the other handle that was behind the first one in the recv pipe of the broken connection is being run, detects that the pipe broke and also starts over in state CONNECT. It finds the pending connection and (re)uses it.
So, now we have two handles in the send pipe of the new connection and the recv pipe is still empty of course.
Next the connection succeeds: the socket becomes writable. The first handle writes its GET request to the server and is moved from the send pipe to the recv pipe.
At this point we enter singlesocket() for this handle and the logic at the top detects that THIS handle now (only) needs reading. It calls the socket callback with only CURL_POLL_IN set. The application therefore removes the previous CURL_POLL_OUT bit for this socket and starts to only listen for a response from the server.
The fact that the send pipe still has the other handle, now at the head, is completely ignored. This new head is not being served because the application isn't looking if the socket is writable.
This bug causes at the very least a delay when things get back into the saddle as a result of, for example, new request is added. Much worse is the scenario where the pipe is full and no new requests are added. I'm not sure yet how exactly, but with the proper timeouts and moving stuff (again) from the recv pipe to the send pipe - I end up with a full send pipe, full with requests that use a socket that is not served - and a 100% locked up multi handle.
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.