> So from VCL, here is how we add VFPs: > > VOID add_vfp(VFP init, ENUM position = DEFAULT); > > VFP is "struct vfp" and any VMOD can return that, thus registering itself as > a VFP. This contains all the callback and its input and output requirements. > > position is: DEFAULT, FRONT, MIDDLE, LAST, FETCH, STEVEDORE > > DEFAULT lets the VMOD recommend a position, otherwise it falls back to LAST. > FETCH and STEVEDORE are special positions which tells Varnish to put the VFP > in front or last, regardless of actual FRONT and LAST.
I think the position should be mapped closer to HTTP semantics: $Enum { content, assembly, encoding, transfer, }; The `content` value would map to Accept/Content-Type headers, working on the original body. The order shouldn't matter (otherwise you are changing the content type) and you could for example chain operations: - js-minification - js-obfuscation You should expect the same results regardless of the order, of course the simplest would be to keep the order set in VCL. The `content` step would feed from storage where the body is buffered. The `assembly` value would map to ESI-like features, and would feed from the content, with built-in support for Varnish's subset of ESI. The `encoding` value would map to Accept-Encoding/Content-Encoding headers. With built-in support for gzip and opening support for other encodings. It would feed from the contents after an optional assembly. The `transfer` value would map to Transfer-Encoding headers, with built-in support for chunked encoding. ZeGermans could implement trailers this way. Would this step make sense in h2? If not, should Varnish just ignore them? Now problems arise if you have an `encoding` step in a VFP (eg. gzip'd in storage) and use `content` or `assembly` steps in a VDP for that same object, or a different encoding altogether. But in your proposal you don't seem bothered by this prospect. Neither am I, because that's only a classic memory vs cpu trade off. But it might be hard to implement the current ESI+gzip optimization if we go this route (or a good reason to go back to upstream zlib). Dridi _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev