Aleks,

On 4/10/21 12:24 AM, Aleksandar Lazic wrote:
+json_string(<json_path>) : string
I don't like the name. A few suggestions:

- json_query
- json_get
- json_decode

maybe json_get_string because there could be some more getter like bool, int, ...

The '_string' suffix does not make sense to me, because why should the user need to write about the expected type when using the converter? Samples already store their type in HAProxy and they are automatically casted to an appropriate type if required (i.e. there is little difference between a numeric string and an int).

It should be valid to do something like this.

str('{"s": "foo", "i": 1}'),json_query('$.s'),sha1,hex

and likewise

str('{"s": "foo", "i": 1}'),json_query('$.i'),add(7)


+      # get the value from the key kubernetes.io/serviceaccount/namespace
+      # => openshift-logging
+      http-request set-var(sess.json) req.hdr(Authorization),b64dec,json_string('$.kubernetes\\.io/serviceaccount/namespace')
+ +      # get the value from the key iss
+      # => kubernetes/serviceaccount
+      http-request set-var(sess.json) req.hdr(Authorization),b64dec,json_string('$.iss')

I don't like that the example is that specific for Kubernetes usage. A more general example would be preferred, because it makes it easier to understand the concept.

The '$.iss' is the generic JWT field.
https://tools.ietf.org/html/rfc7519#section-4.1
"iss" (Issuer) Claim

But even a JWT is a very narrow use-case ...

But maybe I could look for a "normal" JSON sting and only JWT.


... I suggest to use something generic like my example above (with "foo" as a common placeholder value). Examples should explain the concept, not a specific use case. Users are smart enough to understand that they can use this to extract values from a JWT if this is what they need to do.

diff --git a/reg-tests/sample_fetches/json_string.vtc b/reg-tests/sample_fetches/json_string.vtc
new file mode 100644
index 000000000..fc387519b
--- /dev/null
+++ b/reg-tests/sample_fetches/json_string.vtc

Again, this is a converter. Move the test into the appropriate folder. And please make sure you understand the difference between fetches and converters.

Yeah the difference between fetchers and converters in not fully clear for me.
I think when a value is fetched from any data then it's a fetcher like this
JSON "fetcher".

The use of correct terminology is important, because everything else introduces confusion. It is extra important if it is used in persistent documentation (vs. say a discussion in IRC where it can easily be clarified).

The difference is explained in configuration.txt in the introduction of section 7 and again at the beginning of section 7.3.1:

Sample fetch methods may be combined with transformations to be applied on top
of the fetched sample (also called "converters"). These combinations form what
is called "sample expressions" and the result is a "sample".

Fetches *fetch* data from e.g. the connection and then return a *sample*.

Converters *convert* data from an existing *sample* and then return a new *sample*.

-

+ */
+static int sample_check_json_string(struct arg *arg, struct sample_conv *conv,
+                           const char *file, int line, char **err)
+{
+    DPRINTF(stderr, "%s: arg->type=%d, arg->data.str.data=%ld\n",
+                    __FUNCTION__,
+                    arg->type, arg->data.str.data);

Debug code above.

This was intentionally. I asked my self why no Debug option is set.
This will only be printed with 'DEBUG=-DDEBUG_FULL'.
Maybe there should be a "DBUG_SAMPLES" like the other "DEBUG_*" options.

Imagine how the code and also the debug output would look if every converter would output several lines of debug output. Additionally there's not much useful information in the output here. arg->type is always going to be ARGT_STR, because HAProxy will automatically cast the argument based on the converter definition. The length of the string also is pretty much what you expect it to be.

There's also the 'debug' converter that effectively does what that line does.

Don't get me wrong. I also enjoy using 'printf' while debugging my code. But it is going to be removed after I finish debugging. The parts I touch are usually not that complex or deep in the internals that such output would be useful enough in case issues arise.


+    { "json_string", sample_conv_json_string, ARG1(1,STR), sample_check_json_string , SMP_T_STR, SMP_USE_CONST },

While testing something I also just notice that SMP_USE_CONST is incorrect here. I cannot apply e.g. the sha1 converter to the output of json_string.

Best regards
Tim Düsterhus

Reply via email to