My intention was to get pass-through mode working first, since that
will allow me to run varnishd and have things "work" etc.
But now that I think about pass-through mode I realized that it is
not quite as trivial as I thought.
The truly trivial way to do it is to simply act as a pipe: Anything
coming from the client we relay to the backend and vice versa. This
is trivial to implement because no http header parsing or anything
like it is necessary: a simple byte tunnel.
The side effect of this scheme is that if the client does something
which causes a pass-through transaction, then everything else on
that TCP session will bypass the cache and go directly to the
backend. This means amongst other things that rewrites will not
happen on these requests.
Always injecting a "Connection: close" to the backend, so that only
a single transaction will happen is not a solid solution. Not only
does it cost us more TCP connections, but this might also break
some applications which expect to keep the TCP connection open
(authentication private java protocols etc).
The other way is to assume that it is HTTP traffic, do the http
header parsing in both directions and take it from there. (This
is only slightly more code, because a lot of it is reuse.) But, for
that to work it requires that nothing strange is going on and that
the protocol remains HTTP.
So I think my conclusion is that we may need both a "pipe-through"
and a "pass-through" mode, with pass-through being the default
for non GET+HEAD transactions.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
will allow me to run varnishd and have things "work" etc.
But now that I think about pass-through mode I realized that it is
not quite as trivial as I thought.
The truly trivial way to do it is to simply act as a pipe: Anything
coming from the client we relay to the backend and vice versa. This
is trivial to implement because no http header parsing or anything
like it is necessary: a simple byte tunnel.
The side effect of this scheme is that if the client does something
which causes a pass-through transaction, then everything else on
that TCP session will bypass the cache and go directly to the
backend. This means amongst other things that rewrites will not
happen on these requests.
Always injecting a "Connection: close" to the backend, so that only
a single transaction will happen is not a solid solution. Not only
does it cost us more TCP connections, but this might also break
some applications which expect to keep the TCP connection open
(authentication private java protocols etc).
The other way is to assume that it is HTTP traffic, do the http
header parsing in both directions and take it from there. (This
is only slightly more code, because a lot of it is reuse.) But, for
that to work it requires that nothing strange is going on and that
the protocol remains HTTP.
So I think my conclusion is that we may need both a "pipe-through"
and a "pass-through" mode, with pass-through being the default
for non GET+HEAD transactions.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.