sample vmod for req body access & thoughts on req.body and BLOBs

[Poul-Henning Kamp]

--------
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
>  chunk)

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.