MINOR: stream: maintain consistence between channel_forward and HTTP forward
When the HTTP forwarder is used, it resets msg->sov so that we know that
the parsing pointer has advanced by exactly (msg->eoh + msg->eol - msg->sov)
bytes which may have to be rewound in case we want to perform an HTTP fetch
after forwarding has started (eg: upon connect).
But when the backend is in TCP mode, there may be no HTTP forwarding
analyser installed, still we may want to perform these HTTP fetches in
case we have already ensured at the TCP layer that we have a properly
parsed HTTP transaction.
In order to solve this, we reset msg->sov before doing a channel_forward()
so that we can still compute http_rewind() on the pending data. That ensures
the buffer is always rewindable even in mixed TCP+HTTP mode.
diff --git a/src/stream.c b/src/stream.c
index 1003826..0cd5bb6 100644
--- a/src/stream.c
+++ b/src/stream.c
@@ -1987,6 +1987,14 @@
*/
if (!(req->flags & (CF_SHUTR|CF_SHUTW_NOW)))
channel_forward(req, CHN_INFINITE_FORWARD);
+
+ /* Just in order to support fetching HTTP contents after start
+ * of forwarding when the HTTP forwarding analyser is not used,
+ * we simply reset msg->sov so that HTTP rewinding points to the
+ * headers.
+ */
+ if (s->txn)
+ s->txn->req.sov = s->txn->req.eoh + s->txn->req.eol - req->buf->o;
}
/* check if it is wise to enable kernel splicing to forward request data */
@@ -2150,6 +2158,14 @@
if (!(res->flags & (CF_SHUTR|CF_SHUTW_NOW)))
channel_forward(res, CHN_INFINITE_FORWARD);
+ /* Just in order to support fetching HTTP contents after start
+ * of forwarding when the HTTP forwarding analyser is not used,
+ * we simply reset msg->sov so that HTTP rewinding points to the
+ * headers.
+ */
+ if (s->txn)
+ s->txn->rsp.sov = s->txn->rsp.eoh + s->txn->rsp.eol - res->buf->o;
+
/* if we have no analyser anymore in any direction and have a
* tunnel timeout set, use it now. Note that we must respect
* the half-closed timeouts as well.