Envoy 1.26 bump (includes inja bump)

Makefile

@@ -47,7 +47,7 @@ z := $(shell mkdir -p $(OUTPUT_DIR))
 VERSION ?= 1.0.1-dev
 
 SOURCES := $(shell find . -name "*.go" | grep -v test.go)
-ENVOY_GLOO_IMAGE ?= quay.io/solo-io/envoy-gloo:1.25.8-patch1
+ENVOY_GLOO_IMAGE ?= quay.io/solo-io/envoy-gloo:1.26.2-patch3
 LDFLAGS := "-X github.com/solo-io/gloo/pkg/version.Version=$(VERSION)"
 GCFLAGS := all="-N -l"
 
@@ -820,4 +820,4 @@ update-licenses:
 
 # use `make print-MAKEFILE_VAR` to print the value of MAKEFILE_VAR
 
-print-%  : ; @echo $($*)
+print-%  : ; @echo $($*)

changelog/v1.15.0-beta21/envoy-gloo-1-26.yaml

@@ -0,0 +1,34 @@
+changelog:
+- type: DEPENDENCY_BUMP
+  dependencyOwner: solo-io
+  dependencyRepo: envoy-gloo
+  dependencyTag: v1.26.2-patch3
+  issueLink: https://github.com/solo-io/gloo/issues/8177
+  resolvesIssue: false
+  description: >-
+    Use latest envoy-gloo which brings us onto 1.26. This also gives us access
+    to the changes which use the latest version of Inja.
+- type: DEPENDENCY_BUMP
+  dependencyOwner: envoyproxy
+  dependencyRepo: go-control-plane
+  dependencyTag: v0.11.1
+  description: >-
+    Match version which has definitions for 1.26
+- type: DEPENDENCY_BUMP
+  dependencyOwner: envoyproxy
+  dependencyRepo: protoc-gen-validate
+  dependencyTag: v1.0.1
+- type: DEPENDENCY_BUMP
+  dependencyOwner: google.golang.org
+  dependencyRepo: grpc
+  dependencyTag: v1.55.0
+- type: DEPENDENCY_BUMP
+  dependencyOwner: google.golang.org
+  dependencyRepo: protobuf
+  dependencyTag: v1.30.0
+- type: NEW_FEATURE
+  issueLink: https://github.com/solo-io/gloo/issues/8177
+  resolvesIssue: false
+  description: >-
+    Use later version of Inja for transformations (Version 3.4) which provides
+    access to numerous new templating features.

docs/content/guides/traffic_management/request_processing/transformations/_index.md

@@ -10,7 +10,7 @@ To review where transformations happen as Gloo Edge filters traffic, see [Traffi
 
 ## Defining a transformation
 Transformations are defined by adding the `transformations` attribute to your Virtual Services. You can define this attribute on three different Virtual Service sub-resources:
- 
+
 - **VirtualHosts**
 - **Routes**
 - **WeightedDestinations**
@@ -99,19 +99,19 @@ routes:
 {{< /highlight >}}
 
 As stated above, the route's configuration overrides its parent's, but now it also inherits the parent's transformations. So in this case,
-routes matching `/parent` are also transformed. If `inheritTransformation` were set to `false`, the matching `/parent` routes would not be transformed. 
+routes matching `/parent` are also transformed. If `inheritTransformation` were set to `false`, the matching `/parent` routes would not be transformed.
 Note that only the first matched transformation runs, so if both the child and the parent had the same matchers, the child's transformation would run.
 
 ### Configuration format
-Learn more about the properties that you can set in the `stagedTransformations` {{< protobuf display="object" name="transformation.options.gloo.solo.io.TransformationStages" >}} section of your YAML file. 
+Learn more about the properties that you can set in the `stagedTransformations` {{< protobuf display="object" name="transformation.options.gloo.solo.io.TransformationStages" >}} section of your YAML file.
 
-The following YAML file shows a sample structure for how to configure request and response transformations in the `stagedTransformations` section: 
+The following YAML file shows a sample structure for how to configure request and response transformations in the `stagedTransformations` section:
 
 ```yaml
 stagedTransformations:
   early:
     # early transformations
-  regular: 
+  regular:
     requestTransforms:
       - matcher:
           prefix : '/'
@@ -122,7 +122,7 @@ stagedTransformations:
   inheritTransformations: bool
 ```
 
-The `early` and `regular` attributes are used to specify when in the envoy filter chain the transformations run. For request transformations, early transformations are applied before regular transformations as shown in the following diagram. For response transformations, this order is reversed, and regular transformations are applied before early transformations. To learn more about the order in which envoy filters are applied, see [HTTP filter chain processing](https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request#http-filter-chain-processing) in the envoy documentation. 
+The `early` and `regular` attributes are used to specify when in the envoy filter chain the transformations run. For request transformations, early transformations are applied before regular transformations as shown in the following diagram. For response transformations, this order is reversed, and regular transformations are applied before early transformations. To learn more about the order in which envoy filters are applied, see [HTTP filter chain processing](https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request#http-filter-chain-processing) in the envoy documentation.
 
 ![Transformation Filter Stages]({{% versioned_link_path fromRoot="/img/transformation_stages.png" %}})
 
@@ -137,7 +137,7 @@ The `requestTransformation` and `responseTransformation` attributes have the {{<
 - `headerBodyTransform`: This type of transformation makes all the headers available in the body and returns a JSON body that consists of two attributes: `headers`, containing the headers, and `body`, containing the original body.
   - If `addRequestMetadata` is true, `queryString`, `queryStringParameters`, `multiValueQueryStringParameters`, `httpMethod`, `path`, and `multiValueHeaders` will additionally be present in the body.
 - `transformationTemplate`: This type of transformation allows you to define transformation templates. This is the more powerful and flexible type of transformation. For more information, see [Transformation templates](#transformation-templates).
-- `xsltTransformation`: This type of transformation allows you to use the XSLT transformation language to describe your transformation. For more information, see [XSLT Transformation](#xslt-transformation). 
+- `xsltTransformation`: This type of transformation allows you to use the XSLT transformation language to describe your transformation. For more information, see [XSLT Transformation](#xslt-transformation).
 
 The `inheritTransformation` attribute allows child routes to inherit transformations from their parent RouteTables and/or VirtualHosts. For more information, see [Inheritance rules](#inheritance-rules).
 
@@ -151,7 +151,7 @@ transformationTemplate:
   extractors:  {}
   headers: {}
   # Only one of body, passthrough, and mergeExtractorsToBody can be specified
-  body: {} 
+  body: {}
   passthrough: {}
   mergeExtractorsToBody: {}
   dynamicMetadataValues: []
@@ -169,9 +169,9 @@ Let's go ahead and describe each one of these attributes in detail.
 By default, `transformationTemplate` parses the request/response body as JSON, depending on whether you configure a `requestTransformation` or `responseTransformation`. If Gloo Edge fails to parse the request/response body as JSON, it returns a `400 Bad Request` error.
 
 If you want to skip this behavior, you can:
-* Set the [`parseBodyBehavior`](#parsebodybehavior) attribute to `DontParse`. Edge treats the body as plain text and does not parse it.
+* Set the [`parseBodyBehavior`](#parsebodybehavior) attribute to `DontParse`. Edge buffers the body as plain text and does not parse it.
 * Set the [`ignoreErrorOnParse`](#ignoreerroronparse) attribute to `true`. Edge parses the body as JSON, but does not return an error if the body is not valid JSON.
-* Enable [`passthrough`](#passthrough). Edge does not parse the body.
+* Enable [`passthrough`](#passthrough). Edge does not parse or buffer the body.
 {{% /notice %}}
 ##### parseBodyBehavior
 This attribute determines how the request/response body will be parsed and can have one of two values:
@@ -189,7 +189,7 @@ By default, Gloo Edge will attempt to parse the body as JSON, unless you have `D
 Implicit in this setting is that the body will be buffered and available. If you're looking to skip any body buffering completely, see the section [on passthrough: {}](#passthrough)
 
 ##### extractors
-Use this attribute to extract information from a request or response. It consists of a set of mappings from a string to an `extraction`: 
+Use this attribute to extract information from a request or response. It consists of a set of mappings from a string to an `extraction`:
 
 - the `extraction` defines which information will be extracted
 - the string key will provide the extractor with a name it can be referred by.
@@ -309,7 +309,7 @@ As an example, the following configuration snippet could be used to transform a
 ```yaml
 transformationTemplate:
   # [...]
-  body: 
+  body:
     text: '{% if header(":status") == "404" %}{ "error": "Not found!" }{% else %}{{ body() }}{% endif %}'
   # [...]
 ```
@@ -326,7 +326,7 @@ transformationTemplate:
   # [...]
 ```
 
-If you're looking to parse the body, and either [ignore errors on parsing](#ignoreerroronparse), or just [disable JSON parsing](#parsebodybehavior), see those sections in this document, respectively. 
+If you're looking to parse the body, and either [ignore errors on parsing](#ignoreerroronparse), or just [disable JSON parsing](#parsebodybehavior), see those sections in this document, respectively.
 
 ##### mergeExtractorsToBody
 Use this type of body transformation to merge all the `extractions` defined in the `transformationTemplate` to the body. The values of the extractions will be merged to a location in the body JSON determined by their names. You can use separators in the extractor names to nest elements inside the body.
@@ -360,7 +360,7 @@ This will cause the resulting body to include the following extra attributes (in
 ##### dynamicMetadataValues
 This attribute can be used to define an [Envoy Dynamic Metadata](https://www.envoyproxy.io/docs/envoy/latest/configuration/advanced/well_known_dynamic_metadata) entry. This metadata can be used by other filters in the filter chain to implement custom behavior.
 
-As an example, the following configuration creates a dynamic metadata entry in the `com.example` namespace with key  `foo` and value equal to that of the `foo` header . 
+As an example, the following configuration creates a dynamic metadata entry in the `com.example` namespace with key  `foo` and value equal to that of the `foo` header.
 
 ```yaml
 dynamicMetadataValues:
@@ -382,10 +382,10 @@ Please note that, if set to `true`, you will need to use the `extraction` functi
 
 #### Templating language
 {{% notice note %}}
-Templates can be used only if the request/response payload is a JSON string.
+Unless `parseBodyBehavior` is set to `DontParse`, templates can be used only if the request/response payload is a JSON string.
 {{% /notice %}}
 
-Gloo Edge templates are powered by the [Inja](https://github.com/pantor/inja) template engine, which is inspired by the popular [Jinja](https://palletsprojects.com/p/jinja/) templating language in Python. When writing your templates, you can take advantage of all the core _Inja_ features, i.a. loops, conditional logic, and functions.
+Gloo Edge templates are powered by v3.4 of the [Inja](https://github.com/pantor/inja/tree/v3.4.0) template engine, which is inspired by the popular [Jinja](https://palletsprojects.com/p/jinja/) templating language in Python. When writing your templates, you can take advantage of all the core _Inja_ features, i.a. loops, conditional logic, and functions.
 
 In addition to the standard functions available in the core _Inja_ library, you can use additional custom functions that we have added:
 
@@ -412,15 +412,15 @@ xsltTransformation:
 ```
 
 ##### xslt
-The XSLT transformation is specified in this field as a string. Like other transformations, an invalid XSLT transformation will not be accepted and envoy 
+The XSLT transformation is specified in this field as a string. Like other transformations, an invalid XSLT transformation will not be accepted and envoy
 validation will reject the transformation configuration.
 
 ##### setContentType
 XSLT transformations can be used to transform HTTP body between content type. For example, from [XML to JSON](https://www.w3.org/TR/xslt-30/#func-xml-to-json), or [JSON to XML](https://www.w3.org/TR/xslt-30/#func-json-to-xml).
 In the case of these transformations, the `content-type` HTTP header is set to the value of `setContentType`. If left empty, the `content-type` header is unchanged.
 
 ##### nonXmlTransform
-XSLT transformations typically accept only XML as input. If the input to the transformation is not XML, this should be set to true. For example, if 
+XSLT transformations typically accept only XML as input. If the input to the transformation is not XML, this should be set to true. For example, if
 the XSLT transformation is transforming a JSON input to XML, this would be set to `true`. By default, this is false and the XSLT transformation will only accept XML input.
 
 ### Common use cases