thoughts about vcl cleanup around (be)resp.body and abandon/synth

Thu Feb 2 15:06:42 CET 2017

Sorry for being extremely late to this debate.

The fundamental problem is that the body is not like headers, and
IMO trying to make it look like one is a grave mistake.

I am also very surprised that the word "filter" appears nowhere in
the emails in this thread?

We need to decide how VCL produced fetch bodies work with VFP, and why.

If the answer is "They dont", then the "why" part needs a better
answer than "I personally wont need that", because we know there
are users wanting this.

If the answer is "They do", then we need to figure out how VFP's work
in VCL in the first place, before we can progress much.

I think the correct answer is "They do", but I'm willing to be persuaded.

I have been thinking about the VCL/filter issue a lot, and all but
one of my ideas becomes a royal mess to implement.

The one idea which only becomes a mere ducal mess, is that
vcl_backend_response{} gets a new variable named beresp.filter_list
which contains a space-separated list of VFP's to use ("gunzip esi gzip")

If you want modify the filter stack, you edit that beresp.filter_list,
probably with a regsub().

VMODs offering novel filters, must register them, so they can be
found when the list is interpreted, which unfortunately leaves a
hole wrt. to passing parameters from VCL to that filter instance.

As for stuffing actual content through the filters and into the
resp.body, that cannot happen in backend_response{} because we have
neither object, storage or filterstack yet.

The vcl_synth{} vcl_backend_error{} situation is not very satisfying
and trying to build on that seems unwise.

One possible solution, on both client and backend side, would be to
be able to tell what function to call to produce the body, in straw-man
form something like:

	sub my_error {
		body += "<HTML>";
		body += "<H1>" + bereq.url + "</H1>"
		body += vmod.foobar(something, something);
		body += "<BLINK>Because We Can</BLINK>";
		body += "</HTML>";
	}

	sub vcl_backend_response {
		[...]
		set beresp.[...];
		return (synth(my_error));
	}

It goes without saying that the "body-functions" would not be able
to do anything else etc.

Semi-major VCC work in other words...

The final thing I want to say at this point is that before we do
any of this, we need to change how VCL fails.

It used to be that we would try to muddle through when VCL did
something counter-productive, but that is increasingly hard and
increasingly wrong.

I'm not done figuring out how a "VCL botched up" state would look,
inputs welcome.

-- 
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.