> A user doesn't have a means to add VFPs or VDPs via VCL
Well, I guess I meant like this:
beresp.do_esi = true
In effect, the above statement adds the ESI VDP to the beresp. ESI would
not be part of the "builtin" VDPs in this new scheme, rather, its just a
plain old user VDP. Builtins, as
On 12/10/2017 06:36 PM, Reza Naghibi wrote:
> Basically, the user adds VFP
> processors via VCL as usual with an optional position.
What did you mean here by "as usual"? A user doesn't have a means to add
VFPs or VDPs via VCL -- I thought that this discussion is about how that
would work.
>-
>> I think the position should be mapped closer to HTTP semantics
>
> I think this makes too many assumptions? For example, where would security
> processors go? Knowing what I know about whats possible with these things, I
> think the processor universe might be bigger than the 4 categories you
>
> take the protocol-vpfs v1f_* h2_body out of the game for vcl
Those will be builtin on the delivery side. So I didnt really dive into
VDPs, but it works similar to VFPs in that the client expects a certain
kind of response, so its upto the VDP chain to produce a matching output.
So if the client
> - format specifiers:
>
> - have:
>
> (gzip), (plain) *1), (esi)
>
> - ideas:
>
> (br), (buffertext) *2)
>
> esi being a format which can contain gzip segments, but that's would
> be opaque to other vfps
[...]
> *1) "(text)" in reza's concept
> 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,
Hi,
at first, I found Rezas concept appealing and there are some aspects which I
think we should take from it:
- take the protocol-vpfs v1f_* h2_body out of the game for vcl
- format specifiers:
- have:
(gzip), (plain) *1), (esi)
- ideas:
(br),
