Am 21.01.2016 um 17:03 schrieb Jim Jagielski:
Did you want me to work on it, or are you?
I just had some late lunch and started to think closer about it. Since
kept_body was previously only used for request bodies, wouldn't it be
nicer to *not* expose the HC response body under that name in the
expression parser, and instead register an expr extension from HC which
handles a new function, say hc(), with a first supported argument
"body"? So hc(body) returns whatever HC wants to.
You could still use the kept_body field in your impl (or some other
place now or later) but we wouldn't expose this implementation detail to
the outside world.
I have already done an expr function extension in some custom module, it
is pretty easy to do (and httpd uses that feature e.g. in mod_ssl).
So yes, if you like I can do it. But do you like the idea?
Regards,
Rainer
On Jan 21, 2016, at 10:25 AM, Jim Jagielski <j...@jagunet.com> wrote:
Sounds good to me!!
thx!
On Jan 21, 2016, at 10:23 AM, Rainer Jung <rainer.j...@kippdata.de> wrote:
I should have asked earlier: wouldn't it be more suitable to implement to
response body as a variable instead of a function?
When looking at server/util_expr_eval.c, I find request_var_names and
request_var_fn. The former is a list of variable names, and the latter
implements returning the values from parts of the request struct. Returning the
flattened kept_body should be a good fit there as well, without having users
wonder, why it is a function that requires an argument.
If we expect further response stuff coming, we could also clone
request_var_names and request_var_fn with new response_var_names and
response_var_fn and add the variable as the first and currently only one there.
The variable name could be KEPT_BODY.
WDYT? I can also do the little reorg, but which way do we prefer?
Regards,
Rainer
