sample vmod for req body access & thoughts on req.body and BLOBs
phk at phk.freebsd.dk
Tue Mar 10 22:08:47 CET 2015
In message <54FE12BA.2050000 at schokola.de>, Nils Goroll writes:
>- As briefly discussed on the VDD, I think that we should change VMOD BLOBs to
> be struct objcore *
No, we certainly should not tie them to objcore. If we make them iterators,
it will be a general stand alone type of iterator, where implementations can
iterate over anything they want, including objcores.
>- candiates for stringifications should get an additional null byte after the
> blob end (if they don't have it, stringification would replace the last blob
This would be an implementation detail in the iterator-implementation,
ie: the BLOB-iterator for objcores would have a private secret
agreement with the fetch code to always ensure the NUL is there so it
can rely on it.
>- blob2string could just create an obj on the WS
So this is where it gets interesting.
The current STRING_LIST is a sort of cheasy iterator which works really
well when you interpret VCL string concatenation into C source. It is
relevant question if the same iterator mechanism should be used for
STRING(_LIST?) and the current vararg based STRING_LIST would merely
become a convenient VCC implementation of such an iterator.
I need to ponder the pros and cons of this entire thing.
Part of the problem is that C is a shitty language to implement
iterators in (and we have like 4-5 different ones already, don't we ?)
>- WS_Copy is useful, but for stringification f-pointer alignment is in the way
> -> I think we should have WS function variants for unaligned (char *) ptrs.
Performance wise it is a very good idea to align strings, many optimized
versions of string functions rely/expect them to be.
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.
More information about the varnish-dev