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), (buffertext) *2)
esi being a format which can contain gzip segments, but that's would
be opaque to other vfps
- the notion of format conversion(s) that a vfp can handle, e.g.
- have:
esi: (plain)->(esi), (gzip)->(esi)
gzip: (plain)->(gzip)
ungzip: (gzip)->(plain)
- ideas:
br: (plain)->(br)
unbr: (br)->(plain)
re: (plain)->(plain)
But reflecting on it, I am not so sure about runtime resolution and these
aspects in particular:
- "algorithm (...) can reorder the candidates if that allows a match."
- "(A VFP) can (...) add new VFPs to the candidate list, remove itself, remove
other VFPs, or delete itself or other VFPs
I wonder how we would even guarantee that this algorithm ever terminates.
So I think we really need to have VCL compile time checking of all possible
outcomes:
- Either by keeping track of all possible filter chain states at each point
during VCL compilation
- or by restricting ourselves to setting all of the filter chain at once.
The latter will probably lead to largish decision trees in VCL for advanced
cases, but I think we should start with this simple and safe solution with the
format/conversion check.
Nils
*1) "(text)" in reza's concept
*2) not sure if this is a good idea, maybe multi segment regexen are the better
idea
_______________________________________________
varnish-dev mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
