WS/http_conn (Lasse & Martins patches)

[Martin Blix Grydeland]

Hi,

My apologies for having my vacation in the middle of the execution of these
changes. Makes the process halt and context lost. I still hope something
can be salvaged though.

To recap the story, and prepare the others for this as a discussion topic
on the coming VDD, it is to facilitate SSL enabled backends in Varnish.
Having good SSL support with minimum hassle is becoming increasingly
important. To that effort we have released the Hitch project to terminate
the client connections, and using the proxy protocol it interfaces nicely
with Varnish. On the backend side however using a proxy is still cumbersome
and error prone, and solving it should be a priority. I see PHKs arguments
for avoiding libssl in the Varnish source tree, so some other solution
should be found.

We do have the API available to provide Varnish with arbitrary headers and
body bytes through a VMOD backend objects. This is used in
libvmod-fsbackend to read static files from the file system. The API is
complete from this point of view. Implementing SSL backends using VMOD
backend objects would allow us to get "native" to VCL backends without
polluting the Varnish source tree with libssl-linkage.

I've started writing code for this. The parsing of the HTTP headers and
body content doesn't change with SSL, only the reading and writing of bytes
on the socket changes with appropriate calls to the SSL library instead of
the read()/writev() system calls. But reusing the HTTP implementation of
Varnish while changing the way bytes are read/written is impossible in it's
current form. To avoid having to reimplement all of the HTTP/1 code in the
VMOD, I would like to add a set of function pointers associated with a HTTP
connection. The VMOD will then be able to insert it's own read()/writev()
implementation using the appropriate means to encrypt/decrypt. The natural
place to have these function pointers is the struct http_conn.

I sent a patch set to achieve this on dev a while ago. It moved things
around a bit, cleaning up some places but muddled the water a bit in
others. A new sketch for how to design this was worked out with PHK on IRC,
but I couldn't manage to complete the second iteration of the patch set
before my vacation. It's mostly done though, and can be brought to
completion for 4.1.

End of recap.

If I understand PHKs conclusion correctly, he has since been looking at the
code and how to make it right and future proof at a deeper level than my
patch set or the unfinished new sketch attempted. This was found to be too
much of an undertaking this late in the release cycle and thus should be
postponed. I want to argue that the sketched solution, which is close to
completion, should be seriously considered for inclusion in 4.1. I agree
that it doesn't deal with the incestuous relationship with proxy protocol
in any ways, but that is the case with the current code as well. That patch
set would create something that'll be only for the lifetime of 4.x, but
these areas that are bound to see big changes happening with H2 anyway.

If we don't include this and postpone it for 4.2, we push the SSL backend
VMOD forward in time as well. I think this is functionality that it is
important for the project to get sooner rather than later and that would be
a loss.

-Martin

On 17 August 2015 at 10:59, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> Lasse and Martin have sent in a group of patches which hit WS and
> http_conn from either side and I have tried to see if something
> sensible could be done before 4.1 with this area.
>
> I've cherry-picked some bits from the patches and rearranged some
> deck-chairs for better Feng-Shui, but what really needs to happen
> is not something I want to attempt right before 4.1-R.
>
> Here are some gory entrails for those interested:
>
> We originally had two operations on a workspace:  Allocate and Reserve.
>
> The original idea was that one could still do allocations while part of
> the workspace was reserved, but that soon fell by the road-side.
>
> The main user of Reserve was the http_conn receive buffer - we didn't
> want to Alloc a buffer and drag the unused part around, so http_conn
> would reserve and only hang onto what was actually needed.
>
> The secondary user of Reserve is when we don't know how much space
> we will need, but these not really Reservations as much as time-extended
> Allocs.
>
> Later we got the Snapshot/Reset trick as a means for reusing WS,
> but that is really just another shape of Reserve once you look hard
> enough at it.
>
> Next we defined the backend-side timeouts (first/between bytes) in a
> way that makes it very hard to reuse the client side "receive a
> HTTP header" code for the backend.
>
> The http_conn ended up as a sort of H1-proto-state struct which keeps
> track of the existence of a body to be fetched etc.
>
> And then we added PROXY, which uses the http_conn, and has a rather
> incestuous relationship with the HTTP1 code all in all.
>
> And all along we have worked to make out-of-WS a handled error, rather
> than a panic.
>
> Now we're facing H2, which as entirely different wire/mem properties
> than H1, which pretty much violates the assumptions under http_conn.
>
> Some major work will happen here once 4.1 is cut, but to be honest,
> after mucking with it for a week I'm still not entirely sure how it
> should look in the long run...
>
> --
> 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.
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>



-- 
<http://varnish-software.com>*Martin Blix Grydeland*
Senior Developer | Varnish Software AS
Mobile: +47 992 74 756
We Make Websites Fly!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20150828/d999cb65/attachment.html>