Just keeping people apprised of my work on this. For the second time, HTTP state
internals defeated me. The 'bits.close' state does quite a bit of unexpected
flipping between 'on' and 'off' states during request processing. It ended up
being 'on' too often during a check for connection compatibility with pipelining.
This resulted in pipelining mostly being inhibited.

So, I added a bit whose semantics I control. It's used for only one purpose:
preventing requests being assigned to a connection once that connection is
known to be unusable (poisoned). A better solution compatible with the HTTP
state plumbing will have to come from devs more familiar with it.

~~~~
diff -r -U5 curl-7.38.0/lib/multi.c curl/lib/multi.c
--- curl-7.38.0/lib/multi.c 2014-09-07 17:50:41.000000000 -0400
+++ curl/lib/multi.c 2014-10-10 10:52:34.631014500 -0400
@@ -1017,10 +1017,17 @@
         /* Force the connection closed because the server could continue to
            send us stuff at any time. (The disconnect_conn logic used below
            doesn't work at this point). */
         connclose(data->easy_conn, "Disconnected with pending data");
         data->result = CURLE_OPERATION_TIMEDOUT;
+ /* Linden 1420 */
+ if(data->easy_conn) {
+ infof(data, "Request timed out. Signal all requests on connection.\n");
+ data->easy_conn->bits.poisoned_1420 = TRUE;
+ Curl_posttransfer(data);
+ Curl_done(&data->easy_conn, data->result, FALSE);
+ }
         multistate(data, CURLM_STATE_COMPLETED);
         break;
       }
     }
 
diff -r -U5 curl-7.38.0/lib/url.c curl/lib/url.c
--- curl-7.38.0/lib/url.c 2014-09-07 17:50:41.000000000 -0400
+++ curl/lib/url.c 2014-10-10 10:53:54.744754200 -0400
@@ -2694,10 +2694,11 @@
 
 static bool IsPipeliningPossible(const struct SessionHandle *handle,
                                  const struct connectdata *conn)
 {
   if((conn->handler->protocol & PROTO_FAMILY_HTTP) &&
+ !conn->bits.poisoned_1420 && /* Linden 1420 */
      Curl_multi_pipeline_enabled(handle->multi) &&
      (handle->set.httpreq == HTTPREQ_GET ||
       handle->set.httpreq == HTTPREQ_HEAD) &&
      handle->set.httpversion != CURL_HTTP_VERSION_1_0)
     return TRUE;
@@ -3647,11 +3648,12 @@
 #endif /* CURL_DISABLE_PROXY */
 
   conn->bits.user_passwd = (NULL != data->set.str[STRING_USERNAME])?TRUE:FALSE;
   conn->bits.ftp_use_epsv = data->set.ftp_use_epsv;
   conn->bits.ftp_use_eprt = data->set.ftp_use_eprt;
-
+ conn->bits.poisoned_1420 = FALSE; /* Linden 1420 */
+
   conn->verifypeer = data->set.ssl.verifypeer;
   conn->verifyhost = data->set.ssl.verifyhost;
 
   conn->ip_version = data->set.ipver;
 
diff -r -U5 curl-7.38.0/lib/urldata.h curl/lib/urldata.h
--- curl-7.38.0/lib/urldata.h 2014-09-03 09:22:36.000000000 -0400
+++ curl/lib/urldata.h 2014-10-10 10:57:37.745145200 -0400
@@ -543,10 +543,12 @@
                                 connection in a CONNECT request with auth, so
                                 that libcurl should reconnect and continue. */
   bool bound; /* set true if bind() has already been done on this socket/
                  connection */
   bool type_set; /* type= was used in the URL */
+ bool poisoned_1420; /* Linden 1420 - Connection became unusable and must not
+ be considered for pipelining. */
 };
 
 struct hostname {
   char *rawalloc; /* allocated "raw" version of the name */
   char *encalloc; /* allocated IDN-encoded version of the name */
~~~~

---
** [bugs:#1420] Pipelining + client-side timeouts lead to loss of synchronization with response stream and incorrect data delivery**
**Status:** open
**Labels:** pipelining 
**Created:** Tue Sep 02, 2014 10:36 PM UTC by Monty Brandenberg
**Last Updated:** Mon Oct 13, 2014 10:34 PM UTC
**Owner:** nobody
I've been tracking a data corruption/missing http status problem and I think I have enough data for a useful bug report.
The problem centers around the handling of queued requests in a pipeline when preceding requests are failed in libcurl after committing to a request/response transaction.  In the table below, I show six GET requests pipelined on one connection.  'Time' is relative seconds since the creation of the connection.  The first three requests are processed normally.  The fourth request times out while processing the response body.  The fifth request times out waiting for the response header.  The sixth request is allowed to proceed but appears to be out-of-sync with the response stream.  I haven't dumped the data in verbose mode but I'd guess that the sixth request is consuming the remainder of the fourth request's response body in some demented fashion.
Request | Time | Event
------- | ---- | -----
0 | 0 | HEADEROUT issued
0 | 1 | First HEADERIN data
0 | 13 | Request completed, 200 status
1 | 0 | HEADEROUT issued
1 | 13 | First HEADERIN data
1 | 15 | Request completed, 200 status
2 | 0 | HEADEROUT issued
2 | 15 | First HEADERIN data
2 | 20 | Request completed, 200 status
3 | 0 | HEADEROUT issued
3 | 20 | First HEADERIN data
3 | 30 | Timeout declared (easy error 28)
3 | 30 | Request failed, easy 28 status
4 | 0 | HEADEROUT issued
4 | 30 | Timeout declared (easy error 28), no HEADERIN data seen
4 | 30 | Request failed, easy 28 status
5 | 13 | HEADEROUT issued
5 | 30 | First DATAIN received, NO HEADERIN data for this request
5 | 43 | Connection closed.  This may be in response to server socket close.
5 | 43 | Request appears to succeed but CURLINFO_RESPONSE_CODE returns 0.
The sixth request appears to succeed as far as multi_perform and multi_info_read are concerned.  But fetching CURLINFO_RESPONSE_CODE returns 0 for status.  
As a workaround, checking the status as above appears to be useful.  I'm not certain that's 100% reliable or that the connection will be broken immediately at that point.  This has the potential of going very wrong as far as data integrity goes.
If I understand this correctly, solutions would include:
* Canceling/failing a request that's active on a pipeline results in failure to all requests farther down the pipeline.
* Canceling/failing a request results in 'passivation' of the request.  It no longer interacts with the caller but remains active sinking data from the response until satisfied.
---
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.