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.
This commit is contained in:
Willy Tarreau 2015-07-09 18:38:57 +02:00
parent 28d976d5ee
commit 42529c38ac

View File

@ -1987,6 +1987,14 @@ struct task *process_stream(struct task *t)
*/
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 @@ struct task *process_stream(struct task *t)
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.