-
-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
STRING/IP not set expansion #265
base: feat/re-implementation-for-header-value
Are you sure you want to change the base?
STRING/IP not set expansion #265
Conversation
The reason for making Your implementation looks neat but my concern is whether it's okay to determine whether the ident value contains Of course, I understand falco is a different approach for the VCL against Fastly (on the fly vs AST-based) so it makes it difficult to reproduce the VCL behavior. |
My main concern with the approach of trying to put the For example in the case of string concatenation. Not set values will be expanded to
All these different cases require context about where the string concatenation is occurring. It seems to me that the details of handling when to insert
I don't follow what you mean here, could you please elaborate? |
It looks like a NotSet state is determined for each context independently. My concern is... NotSet string should be affected following statement and do we need to keep the NotSet state the following statements, for example: declare local var.S STRING;
set req.http.Foo = var.S;
log req.http.Foo; // => "(null)" string (1)
set req.http.Foo = req.http.Foo var.S;
log req.http.Foo; // => "(null)" string, not "(null)(null)" (2) Fiddle is here https://fiddle.fastly.dev/fiddle/ccf10a57 |
Ah! You found the one case I forgot to include a test for, nice. The concatenation of two unset values yields an unset value regardless of the target of the assignment. The first assignment leaves the Your example is functionally equivalent to: declare local var.s STRING;
set req.http.foo = req.http.bar var.s; Fixed this case and added a test for it in my validation cases. |
Okay, If your implementation covers it, my concern will be solved, thanks. |
Rebase of the ProcessExpression based not_set expansion solution onto the #248 branch.
Setting this as a draft because I had to make a change to the LenientString to make the changes needed for the expression handling work correctly. With that change it largely removes half of the utility of the type which reinforces my feeling that the new type really isn't needed.