Hi Lokesh, On Fri, Aug 25, 2023 at 01:44:48PM -0700, Lokesh Jindal wrote: > Hey folks > > I am writing to gather feedback on an idea before doing the implementation. > Per the documentation, converter "bytes" accepts integer values as > arguments, but not txn args. > i.e. <fetch>,bytes(2,8) will work > but <fetch>,bytes(txn.start_idx,txn.length) will not work. > > For our use case, we need to parse some binary data (a cookie) to extract > some info in haproxy. However, the bytes that need to be extracted are not > fixed and will depend on the request. We could use simple arithmetic to > determine the index/length for bytes to be extracted and store them in txn > args. These txn args can then be used with converter "bytes". > > I can see that the converter "sub" already supports txn args as arguments. > I have successfully validated the proposed idea with an implementation > following the same pattern as "sub".
In fact it's not "txn", it's variables in general. Most of the arithmetic functions support a variable name as an alternative to a numeric value. I tend to think it would indeed make sense to support both integers and variables for bytes(), it could even be the same for a few other ones (maybe field(), word(), ltrim(), rtrim() etc). > Let me know what you think. If there are no concerns, I can send a patch. I'm all for it. We need to decide what to do when the variable does not exist or is empty. We can't make converters fail for now, so most likely it will have to end up as value zero for offset and/or length. Thanks, Willy
