VIP9: Expand VCL object support

Synopsis

Currently objects are limited to global objects which have a lifetime of the entire VCL. This VIP is to have objects which can be created during the request and their scope is limited to that request. When the request is done, the objects are destructed.

Original VIP9 date: April 25, 2016

Updated VIP9 date: November 18, 2019

Why?

By allowing VMOD objects to live in the request scope, we can easily bring in OO style typed variables to VCL. For example, integers, strings, doubles, lists, hash tables, anything and everything.

How

Here is a VCL snippet which compiles and works with the patch [0] and uses a new libvmod_types [1].

vcl 4.1;

import types;

sub vcl_init
{
  //global objects, these are unchanged
  new s = types.string("Hello!");
  new reqs = types.integer(0);
}

sub vcl_recv
{
  //new req scoped objects
  new slocal = types.string("Request scoped string");
  new s2 = types.string("request string two");
  new count = types.integer(1);
}

sub vcl_backend_fetch
{
  //new bereq scoped objects
  new sbe = types.string("berequest string v1");
  set bereq.http.sbe = sbe.value();

  sbe.set("berequest string v2");
  set bereq.http.sbe2 = sbe.value();
}

sub vcl_deliver
{
  //referencing a mix of global and req scoped objects
  set resp.http.X-s = s.value();
  set resp.http.X-s-length = s.length();

  set resp.http.X-slocal = slocal.value();
  set resp.http.X-slocal-length = slocal.length();

  count.increment(10);
  set resp.http.count = count.value();
  set resp.http.reqs = reqs.increment_get(1);
}

Notes

This patch is by no means the final product. Rather, its meant to show how simple a request scoped object implementation can be and to start building consensus on what the final product should look like.

Here is a list of things that need to be done:

• Introduce a $scope .vcc attribute which ties an object to either global or local scope. All 'legacy' objects would default into a global scope. vmod_types is both global and locally scoped, so it has to use mutexes around everything. If re-implemented as local scope, it would be an extremely simple and straight forward vmod to write and support. This would make implementing all the different basic language types trivial.

• Iron out priv_task rough edges. If this were to move forward, we should introduce a special type which is made for objects and can be shared between local and global scopes. Currently there are 2 different implementations in play in this patch. Making this better could possibly include introducing breaking changes to objects.

• Address uninitialized objects. Its always going to be possible to exit a sub early and leave an object uninitialized. There are ways to detect this and error out.

[-1] 2016 https://github.com/rezan/varnish-cache/commit/b547bd9ad2fca9db1ef17ee73b8e9b7df9950c34

[0] 2019 https://github.com/varnishcache/varnish-cache/compare/master...rezan:req_objects

[1] https://github.com/rezan/libvmod-types