<div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>End of recap.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Martin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 August 2015 at 10:59, Poul-Henning Kamp <span dir="ltr"><<a href="mailto:phk@phk.freebsd.dk" target="_blank">phk@phk.freebsd.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lasse and Martin have sent in a group of patches which hit WS and<br>
http_conn from either side and I have tried to see if something<br>
sensible could be done before 4.1 with this area.<br>
<br>
I've cherry-picked some bits from the patches and rearranged some<br>
deck-chairs for better Feng-Shui, but what really needs to happen<br>
is not something I want to attempt right before 4.1-R.<br>
<br>
Here are some gory entrails for those interested:<br>
<br>
We originally had two operations on a workspace:  Allocate and Reserve.<br>
<br>
The original idea was that one could still do allocations while part of<br>
the workspace was reserved, but that soon fell by the road-side.<br>
<br>
The main user of Reserve was the http_conn receive buffer - we didn't<br>
want to Alloc a buffer and drag the unused part around, so http_conn<br>
would reserve and only hang onto what was actually needed.<br>
<br>
The secondary user of Reserve is when we don't know how much space<br>
we will need, but these not really Reservations as much as time-extended<br>
Allocs.<br>
<br>
Later we got the Snapshot/Reset trick as a means for reusing WS,<br>
but that is really just another shape of Reserve once you look hard<br>
enough at it.<br>
<br>
Next we defined the backend-side timeouts (first/between bytes) in a<br>
way that makes it very hard to reuse the client side "receive a<br>
HTTP header" code for the backend.<br>
<br>
The http_conn ended up as a sort of H1-proto-state struct which keeps<br>
track of the existence of a body to be fetched etc.<br>
<br>
And then we added PROXY, which uses the http_conn, and has a rather<br>
incestuous relationship with the HTTP1 code all in all.<br>
<br>
And all along we have worked to make out-of-WS a handled error, rather<br>
than a panic.<br>
<br>
Now we're facing H2, which as entirely different wire/mem properties<br>
than H1, which pretty much violates the assumptions under http_conn.<br>
<br>
Some major work will happen here once 4.1 is cut, but to be honest,<br>
after mucking with it for a week I'm still not entirely sure how it<br>
should look in the long run...<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20<br>
phk@FreeBSD.ORG         | TCP/IP since RFC 956<br>
FreeBSD committer       | BSD since 4.3-tahoe<br>
Never attribute to malice what can adequately be explained by incompetence.<br>
<br>
_______________________________________________<br>
varnish-dev mailing list<br>
<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" rel="noreferrer" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div><table border="0" cellpadding="0" cellspacing="0" style="font-size:12px;line-height:1.5em;font-family:'Helvetica Neue',Arial,sans-serif;color:rgb(102,102,102);width:550px;border-top-width:1px;border-top-style:solid;border-top-color:rgb(238,238,238);border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);margin-top:20px;padding-top:5px;padding-bottom:5px"><tbody><tr><td width="100"><a href="http://varnish-software.com" target="_blank"><img src="http://www.varnish-software.com/static/media/logo-email.png"></a><span></span><span></span></td><td><strong style="font-size:14px;color:rgb(34,34,34)">Martin Blix Grydeland</strong><br>Senior Developer | Varnish Software AS<br>Mobile: +47 992 74 756<br><span style="font-weight:bold">We Make Websites Fly!</span></td></tr></tbody></table></div></div></div></div>
</div>