text:
The request body is not URL encoded if the mime type is "application/x-www-form-urlencoded"

Environment

Operating System: Windows_NT
Node Version:     v22.8.0
Nuxt Version:     3.13.1
CLI Version:      3.13.1
Nitro Version:    2.9.7
Package Manager:  npm@10.8.2
Builder:          -
User Config:      app, ssr, devtools, compatibilityDate, modules, i18n, openFetch, pinia, primevue, testUtils, typescript
Runtime Modules:  @nuxt/eslint@0.3.13, @nuxtjs/i18n@8.5.3, @nuxtjs/tailwindcss@6.12.1, @nuxt/test-utils/module@3.14.2, @pinia/nuxt@0.5.4, @primevue/nuxt-module@4.0.6, nuxt-open-fetch@0.9.2, nuxt-permissions@0.2.4
Build Modules:    -

Reproduction
I try to create a REST request to perform authentication. The body must be url encoded. My API is the following:
{
 "openapi": "3.1.0",
 "info": { "title": "FastAPI", "version": "0.1.0" },
 "servers": [{ "url": "/auth" }],
 "paths": {
   "/login": {
     "post": {
       "summary": "Auth:Jwt.Login",
       "operationId": "auth_jwt_login_login_post",
       "requestBody": {
         "content": {
           "application/x-www-form-urlencoded": {
             "schema": {
               "$ref": "#/components/schemas/Body_auth_jwt_login_login_post"
             }
           }
         },
         "required": true
       },
       "responses": {
         "200": {
           "description": "Successful Response",
           "content": {
             "application/json": {
               "schema": { "$ref": "#/components/schemas/BearerResponse" },
               "example": {
                 "access_token": "ey...",
                 "token_type": "bearer"
               }
             }
           }
         },
         "400": {
           "description": "Bad Request",
           "content": {
             "application/json": {
               "schema": { "$ref": "#/components/schemas/ErrorModel" },
               "examples": {
                 "LOGIN_BAD_CREDENTIALS": {
                   "summary": "Bad credentials or the user is inactive.",
                   "value": { "detail": "LOGIN_BAD_CREDENTIALS" }
                 },
                 "LOGIN_USER_NOT_VERIFIED": {
                   "summary": "The user is not verified.",
                   "value": { "detail": "LOGIN_USER_NOT_VERIFIED" }
                 }
               }
             }
           }
         },
         "422": {
           "description": "Validation Error",
           "content": {
             "application/json": {
               "schema": { "$ref": "#/components/schemas/HTTPValidationError" }
             }
           }
         }
       }
     }
   }
 },
 "components": {
   "schemas": {
     "BearerResponse": {
       "properties": {
         "access_token": { "type": "string", "title": "Access Token" },
         "token_type": { "type": "string", "title": "Token Type" }
       },
       "type": "object",
       "required": ["access_token", "token_type"],
       "title": "BearerResponse"
     },
     "Body_auth_jwt_login_login_post": {
       "properties": {
         "grant_type": {
           "anyOf": [
             { "type": "string", "pattern": "password" },
             { "type": "null" }
           ],
           "title": "Grant Type"
         },
         "username": { "type": "string", "title": "Username" },
         "password": { "type": "string", "title": "Password" },
         "scope": { "type": "string", "title": "Scope", "default": "" },
         "client_id": {
           "anyOf": [{ "type": "string" }, { "type": "null" }],
           "title": "Client Id"
         },
         "client_secret": {
           "anyOf": [{ "type": "string" }, { "type": "null" }],
           "title": "Client Secret"
         }
       },
       "type": "object",
       "required": ["username", "password"],
       "title": "Body_auth_jwt_login_login_post"
     },
     "ValidationError": {
       "properties": {
         "loc": {
           "items": { "anyOf": [{ "type": "string" }, { "type": "integer" }] },
           "type": "array",
           "title": "Location"
         },
         "msg": { "type": "string", "title": "Message" },
         "type": { "type": "string", "title": "Error Type" }
       },
       "type": "object",
       "required": ["loc", "msg", "type"],
       "title": "ValidationError"
     }
   }
 }
}

The generated API client with Nuxt Open Fetch is the following:
export interface paths {
  "/login": {
    parameters: {
      query?: never;
      header?: never;
      path?: never;
      cookie?: never;
    };
    get?: never;
    put?: never;
    /** Auth:Jwt.Login */
    post: operations["auth_jwt_login_login_post"];
    delete?: never;
    options?: never;
    head?: never;
    patch?: never;
    trace?: never;
  };
}
export type webhooks = Record<string, never>;
export interface operations {
  auth_jwt_login_login_post: {
    parameters: {
      query?: never;
      header?: never;
      path?: never;
      cookie?: never;
    };
    requestBody: {
      content: {
        "application/x-www-form-urlencoded": components["schemas"]["Body_auth_jwt_login_login_post"];
      };
    };
    responses: {
      /** @description Successful Response */
      200: {
        headers: {
          [name: string]: unknown;
        };
        content: {
          "application/json": components["schemas"]["BearerResponse"];
        };
      };
      /** @description Bad Request */
      400: {
        headers: {
          [name: string]: unknown;
        };
        content: {
          "application/json": components["schemas"]["ErrorModel"];
        };
      };
      /** @description Validation Error */
      422: {
        headers: {
          [name: string]: unknown;
        };
        content: {
          "application/json": components["schemas"]["HTTPValidationError"];
        };
      };
    };
  };
}
export interface components {
  schemas: {
    /** BearerResponse */
    BearerResponse: {
      /** Access Token */
      access_token: string;
      /** Token Type */
      token_type: string;
    };
    /** Body_auth_jwt_login_login_post */
    Body_auth_jwt_login_login_post: {
      /** Grant Type */
      grant_type?: string | null;
      /** Username */
      username: string;
      /** Password */
      password: string;
      /**
       * Scope
       * @default
       */
      scope: string;
      /** Client Id */
      client_id?: string | null;
      /** Client Secret */
      client_secret?: string | null;
    };
    /** ErrorModel */
    ErrorModel: {
      /** Detail */
      detail: string | {
        [key: string]: string | undefined;
      };
    };
    /** ValidationError */
    ValidationError: {
      /** Location */
      loc: (string | number)[];
      /** Message */
      msg: string;
      /** Error Type */
      type: string;
    };
    /** HTTPValidationError */
    HTTPValidationError: {
      /** Detail */
      detail?: components["schemas"]["ValidationError"][];
    };
  };
}

I have developped a Pinia store to rend the request login. As follow
import type { components as AuthComponents } from '#open-fetch-schemas/auth'
import type { AuthenticationStateI } from '~/utils/types/AuthenticationState.interface';
import type { UserJwtAutenticiation } from '~/utils/types/UserAutentication.interface';
import { FetchError } from "ofetch";

export const authenticationStore = defineStore('authenticationStore', {
  /**
   *
   * @returns
   */
  state: (): AuthenticationStateI => ({
    bearer: undefined,
    authenticated: false

  }),
  actions: {
    async login(userAuthentication: AuthComponents["schemas"]["Body_auth_jwt_login_login_post"]): Promise<FetchError | undefined> {
      switch (userAuthentication.grant_type) {
        case 'password':
          return await this.passwordLogin(userAuthentication)
        default:
          return Promise.reject(new FetchError('Unknown user authentication grant type'))
      }
    },

    async passwordLogin(userAuthentication: AuthComponents["schemas"]["Body_auth_jwt_login_login_post"]): Promise<FetchError | undefined> {
      const { data, error, status } = await useAuth('/login', {
        method: 'post',
        body: userAuthentication,
        headers: {
          'Content-Type': 'application/x-www-form-urlencoded'
        },
        watch: false,
      })

      if (data.value && status.value !== 'error') {
        this.bearer = data.value
        this.authenticated = true
      } else {
        this.bearer = null
        this.authenticated = false
      }

      return error.value as FetchError | undefined
    }
  }
})

Describe the bug
The login method, the body is in JSON and not URL encoded.
The request header is
POST /auth/login HTTP/1.1
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 91
Host: localhost:7000
Origin: http://localhost:3000
Pragma: no-cache
Referer: http://localhost:3000/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
accept: application/json
content-type: application/x-www-form-urlencoded
sec-ch-ua: "Not/A)Brand";v="8", "Chromium";v="126", "Google Chrome";v="126"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"

The request body is in JSON format
{
  "username": "me@mydomain.com",
  "password": "***",
  "scope": "",
  "grant_type": "password"
}

As the content type is "application/x-www-form-urlencoded", the expected body should be:
grant_type=password&username=me%mydomain.com&password=***

The response has as status 422. The response body is :
{
    "detail": [
        {
            "type": "missing",
            "loc": [
                "body",
                "username"
            ],
            "msg": "Field required",
            "input": null
        },
        {
            "type": "missing",
            "loc": [
                "body",
                "password"
            ],
            "msg": "Field required",
            "input": null
        }
    ]
}

If y send an URL encoded string instead of an object in the body, the IDE linter detects that the format is not as expected.
NuxtOpenFetch API should parse the data in url encoded according to the mime type.
Additional context
No response
Logs
No response

Hi @xavier-ottolini,
NuxtOpenFetch is just a typed wrapper around https://nuxt.com/docs/api/composables/use-fetch and https://nuxt.com/docs/api/utils/dollarfetch.
Ofetch (used under the hood) works the other way around, checking the body type.
You can pass URLSearchParams object and it will automatically add application/x-www-form-urlencoded header for you:
const body = new URLSearchParams({ foo: 'bar' })

await useAuth('/login', {
  method: 'post',
  body,
  watch: false,
})

Reference: https://github.com/unjs/ofetch/issues/33

There is en error message:

authors: enkot xavier-ottolini

repo: enkot/nuxt-open-fetch


text:
🛑 Aarohisilk is down

In e69b840, Aarohisilk (https://aarohisilks.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Aarohisilk is back up in 285aa4c after 4 hours, 42 minutes.

source: gharchive/issue

repo: enlivenonedrive/upptime

license: MIT

license_type: permissive

license_source: github-api


text:
Issue: browse did not produce an answer (error: connect ECONNREFUSED 127.0.0.1:4519).

Describe the bug
i am not able to use /browse option cause i am getting that error Issue: browse did not produce an answer (error: connect ECONNREFUSED 127.0.0.1:4519).
Where is it happening?

Which device [Mobile/Desktop, os version]: i am using a windows 11 pc
Which browser: Chrome V 120.0.6099.110 (Official Build) (64-bit)
Which website: https://google.com

To Reproduce
1- start chrome with debug mode
2- use the ws:// it gives in the game http://[127.0.0.1:4519/json/version ( i used 4519 as port for my debug cmd )
3- put that url in big-agi performance tab under browser dropdown.
4- try to chat /browse google.com
Expected behavior
Issue: browse did not produce an answer (error: connect ECONNREFUSED 127.0.0.1:4519).
Screenshots / context
i got the data from chrome's network tab :
This is the request the BIG-AGI sent :
fetch("http://localhost:3000/api/trpc-node/browse.fetchPages", {
  "headers": {
    "accept": "*/*",
    "accept-language": "en-US,en;q=0.9",
    "content-type": "application/json",
    "sec-ch-ua": "\"Not_A Brand\";v=\"8\", \"Chromium\";v=\"120\", \"Microsoft Edge\";v=\"120\"",
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": "\"Windows\"",
    "sec-fetch-dest": "empty",
    "sec-fetch-mode": "cors",
    "sec-fetch-site": "same-origin"
  },
  "referrer": "http://localhost:3000/",
  "referrerPolicy": "strict-origin-when-cross-origin",
  "body": "{\"json\":{\"access\":{\"dialect\":\"browse-wss\",\"wssEndpoint\":\"ws://127.0.0.1:4519/devtools/browser/156e0aa1-52bc-4bb5-8564-0e5781aca458\"},\"subjects\":[{\"url\":\"https://google.com\"}],\"screenshot\":null},\"meta\":{\"values\":{\"screenshot\":[\"undefined\"]}}}",
  "method": "POST",
  "mode": "cors",
  "credentials": "omit"
});

the request body in pretty view
{"json":{"access":{"dialect":"browse-wss","wssEndpoint":"ws://127.0.0.1:4519/devtools/browser/156e0aa1-52bc-4bb5-8564-0e5781aca458"},"subjects":[{"url":"https://google.com"}],"screenshot":null},"meta":{"values":{"screenshot":["undefined"]}}}

The Response it got back :
{
    "result": {
        "data": {
            "json": {
                "pages": [
                    {
                        "url": "https://google.com",
                        "content": "",
                        "error": "connect ECONNREFUSED 127.0.0.1:4519",
                        "stopReason": "error"
                    }
                ]
            }
        }
    }
}

its fixed , i dont know how
i download chrome Dev version then i closed everything stopped my ollama , stopped big-agi restarted everything all of sudden it works yuy!!

Nice! You should also look into the Browserless containers. There's a doc for that. Very good results.

authors: enricoros mrbeandev

repo: enricoros/big-AGI


text:
[Feature] 非同期API

[x] BAD ACCESSする問題の解消

一旦closeで

source: gharchive/pull-request

repo: ensan-hcl/AzooKeyKanaKanjiConverter


text:
Creating datalinks programmatically

Currently there's no way to create a datalink from Enso code.
It is not only useful for users and library creators but it is also needed so that our datalink tests could be made self-sufficient, not expecting an existing setup on the test account.

I've already adapted our data link tests to create the datalinks themelves... but I forgot it's not yet possible:
Index: test/Base_Tests/data/datalinks/example-enso-file.datalink
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/test/Base_Tests/data/datalinks/example-enso-file.datalink b/test/Base_Tests/data/datalinks/example-enso-file.datalink
--- a/test/Base_Tests/data/datalinks/example-enso-file.datalink	(revision 113524b039474a92844622232e9572b30f26f248)
+++ b/test/Base_Tests/data/datalinks/example-enso-file.datalink	(date 1712768831228)
@@ -1,5 +1,5 @@
 {
     "type": "Enso_File",
     "libraryName": "Standard.Base",
-    "path": "enso://PLACEHOLDER_ORG_NAME/test-directory/another.txt"
+    "path": "enso://PLACEHOLDER_ORG_NAME/PLACEHOLDER_PATH"
 }
Index: test/Base_Tests/src/Network/Enso_Cloud/Cloud_Data_Link_Spec.enso
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/test/Base_Tests/src/Network/Enso_Cloud/Cloud_Data_Link_Spec.enso b/test/Base_Tests/src/Network/Enso_Cloud/Cloud_Data_Link_Spec.enso
--- a/test/Base_Tests/src/Network/Enso_Cloud/Cloud_Data_Link_Spec.enso	(revision 113524b039474a92844622232e9572b30f26f248)
+++ b/test/Base_Tests/src/Network/Enso_Cloud/Cloud_Data_Link_Spec.enso	(date 1712769039360)
@@ -11,24 +11,40 @@

 import project.Network.Enso_Cloud.Cloud_Tests_Setup.Cloud_Tests_Setup

-add_specs suite_builder setup:Cloud_Tests_Setup = setup.with_prepared_environment <|
+type Temporary_Directory
+    Value ~get
+
+    make -> Temporary_Directory = Temporary_Directory.Value <|
+        name = "test-run-Data_Link-"+(Date_Time.now.format "yyyy-MM-dd_HHmmss.fV" . replace "/" "|")
+        root = Panic.rethrow <| Enso_File.root.create_directory name
+
+        Panic.rethrow <| Data_Link_Format.write_raw_config (root / "TestDataLink-HTTP.datalink") http_data_link_content
+        Panic.rethrow <| Data_Link_Format.write_raw_config (root / "TestDataLink-S3.datalink") s3_data_link_content
+        my_target_enso_file = "Hello Enso Cloud File!".write (root / "my-file.txt")
+        Panic.rethrow <| Data_Link_Format.write_raw_config (root / "TestDataLink-EnsoFile.datalink") (enso_file_data_link_content.replace "<PATH>" my_target_enso_file.path)
+
+        root
+
+    cleanup self = self.get.delete_if_exists
+
+add_specs suite_builder setup:Cloud_Tests_Setup =
     suite_builder.group "DataLinks in Enso Cloud" pending=setup.real_cloud_pending group_builder->
+        test_root = Temporary_Directory.make
+        group_builder.teardown test_root.cleanup
+
         group_builder.specify "should be able to access an example HTTP data-link" <|
-            ## We assume that the cloud has a sample data-link called `TestDataLink` present
-               TODO in future iterations this file will be created by the test suite itself, to make it self-contained
-            assets = Enso_File.root.list
-            datalink = assets.find a-> a.name.starts_with "TestDataLink-HTTP"
+            datalink = test_root.get / "TestDataLink-HTTP.datalink"
             datalink.should_be_a Enso_File
             datalink.asset_type.should_equal Enso_Asset_Type.Data_Link

-            # We assume that the datalink points to https://raw.githubusercontent.com/enso-org/enso/develop/test/Base_Tests/data/sample.txt
-            r = datalink.read
-            r.should_be_a Text
-            r.should_contain "Cupcake"
+            Test.with_retries <|
+                # We assume that the datalink points to
+                r = datalink.read
+                r.should_be_a Text
+                r.should_contain "Cupcake"

         group_builder.specify "will report which library is missing if a datalink relying on other library is accessed" <|
-            assets = Enso_File.root.list
-            datalink = assets.find a-> a.name.starts_with "TestDataLink-S3"
+            datalink = test_root.get / "TestDataLink-S3.datalink"
             datalink.should_be_a Enso_File
             datalink.asset_type.should_equal Enso_Asset_Type.Data_Link

@@ -44,14 +60,12 @@
                 Data_Link_Format.read_raw_config temp_file

         group_builder.specify "should be able to read a local datalink to an Enso File" <|
-            datalink = replace_org_name_in_data_link (enso_project.data / "datalinks" / "example-enso-file.datalink")
-            datalink.read . should_equal "Hello Another!"
+            datalink = replace_placeholder_path (enso_project.data / "datalinks" / "example-enso-file.datalink") (test_root.get / "my-file.txt")
+            datalink.read . should_equal "Hello Enso Cloud File!"

         group_builder.specify "should be able to read a datalink in the Cloud to Enso File" <|
-            # TODO currently this link is created manually, later we should be generating it as part of the test
-            datalink = Enso_File.new "enso://"+Enso_User.current.organization_name+"/TestDataLink-EnsoFile"
-            datalink.read . should_equal "Hello Another!"
-
+            datalink = Enso_File.new test_root.get.path+"/TestDataLink-EnsoFile.datalink"
+            datalink.read . should_equal "Hello Enso Cloud File!"

 main filter=Nothing =
     setup = Cloud_Tests_Setup.prepare
@@ -61,9 +75,34 @@

 ## Reads the datalink as plain text and replaces the placeholder organization name.
-replace_org_name_in_data_link base_file =
-    content = Data_Link_Format.read_raw_config base_file
-    org_name = Enso_User.current.organization_name
-    new_content = content.replace "PLACEHOLDER_ORG_NAME" org_name
-    temp_file = File.create_temporary_file prefix=base_file.name suffix=base_file.extension
+replace_placeholder_path datalink_file target_file =
+    content = Data_Link_Format.read_raw_config datalink_file
+    new_content = content.replace "enso://PLACEHOLDER_ORG_NAME/PLACEHOLDER_PATH" target_file.path
+    temp_file = File.create_temporary_file prefix=datalink_file.name suffix=datalink_file.extension
     Data_Link_Format.write_raw_config temp_file new_content replace_existing=True . if_not_error temp_file
+
+http_data_link_content = """
+    {
+        "type": "HTTP",
+        "libraryName": "Standard.Base",
+        "method": "GET",
+        "uri": "https://raw.githubusercontent.com/enso-org/enso/develop/test/Base_Tests/data/sample.txt"
+    }
+
+s3_data_link_content = """
+    {
+      "type": "S3",
+      "libraryName": "Standard.AWS",
+      "uri": "s3://enso-data-samples/examples/folder 2/hello.txt",
+      "auth": {
+        "type": "aws_auth",
+        "subType": "default"
+      }
+    }
+
+enso_file_data_link_content = """
+    {
+        "type": "Enso_File",
+        "libraryName": "Standard.Base",
+        "path": "<PATH>"
+    }

The goal of this ticket would be to apply this patch and ensure it actually works - we need to intercept a with_output_stream that targets a .datalink and ensure it instead performs a different POST request - to the create_connector endpoint instead of upload_file.

repo: enso-org/enso


text:
Community Meeting January 24th, 2024

Overview
At 10am Eastern, 7am Pacific, 2pm UTC; find your time
Video call link: https://meet.google.com/ved-ivnv-aen
dial-in: (US) +1 409-444-2447
PIN: 873 550 579#
More phone numbers: tel.meet/ved-ivnv-aen?pin=7872592963542&hs=1
Add topics you'd like to discuss below!

I'd like to discuss "acceptable bundles" as described here.

The list of acceptable bundles is time based. A bundle that is acceptable today is not necessarily acceptable tomorrow. The list below may contain bundles that are "too old" and no longer acceptable. The reason for this behavior is to allow users a certain period of time to upgrade to a newer bundle.

The concept of entries being "too old" is confusing, making it hard to get the implementation right, and even to explain how it is supposed to work for users.
To further complicate things, the complete feature is implemented partially in ec-cli and partially in ec-policies.
Maybe it's time to find an alternate approach?
(Also somewhat related to https://github.com/enterprise-contract/ec-cli/issues/1291)

If we have time, it might be good to discuss how we're tackling effective_on in rule_data.yml.

Meeting recording: https://drive.google.com/file/d/1hZKzVfxk8_GANKn_8vRTpo0dIhFYW1Gc/view?usp=drive_link

authors: lcarva mbestavros robnester-rh

repo: enterprise-contract/community


text:
stats: add event tracker for android

Adds event tracker for android.
The ios change was done a few days ago: https://github.com/envoyproxy/envoy-mobile/pull/1602
This pr also adds an event tracker to the kotlin example app. Sample logs:

Description:
Risk Level: low, extensively tested
Testing: example app, unit testing & ci
Docs Changes: done
Release Notes: Adds event tracker for android
Signed-off-by: Jingwei Hao jingwei.hao@gmail.com

Overall looks good; see comments.

repo: envoyproxy/envoy-mobile

license_source: bigquery


text:
ext_authz: allow updating path querystring when allowing request

Description:
I'd love to have the capability to update/rewrite the query string of the request in an ext_authz response before it is forwarded upstream.
This feature would be useful in scenarios where it is required to strip sensitive information from the request before forwarding it upstream. An example use case is APIs where apikey is provided as query parameter.
e.g.

client retrieves http://api/users/1?apikey=abc&format=json

ext_authz checks key abc in database and allows request

ext_authz responds with updated path/query string without apikey=abc

upstream retrieves request for /users/1?format=json

(My main need is to to be able to update query parameter string before forwarding the request, but one could reason a more generic implementation could be to allow updating the full path)

So this is similar to allowed_upstream_headers (e.g. to be able to state: I only allow header-name and content-type to be forwarded to upstream) but for query params?

Indeed, you could see it like allowed_upstream_headers : a way to specify which query parameters are allowed to go upstream.
But.. such allowed list implementation is not ideal for the scenario described above: given I have tens of upstreams I'd rather not specify all possible query parameters supported by those upstreams.
It's more the opposite: in my case I'd like to be able to drop both query parameter apikey and key before the request goes upstream, as either can be used by my customers.
So for my use case I would be more looking for a feature like disallowed_queryparameters as part of AuthorizationResponse instead of allowed_queryparameters  (perhaps somebody has a usecase for allowed_queryparameters..)
Let me know if this makes sense!

authors: dio erikbos

repo: envoyproxy/envoy


text:
External Edge proxy resets grpc-web server-to-client streams.

Title: External Edge proxy resets the connection
Description:
I am running a following setup: Internet ----> Edge Envoy proxy(L1) ----> Istio Ingress gateway (L2) ----> App (with envoy sidecar)
The app utilizes grpc-web (server-to-client long-lived streams). The only two things I want L1 to do is:

Route traffic based on the host header
TLS termination

It does both of the above perfectly, however, when it was introduced, our grpc-web streams started to timeout/reset at various intervals (typically 2-10 minutes), causing net::ERR_CONNECTION_RESET (chrome dev tools). These connection resets do not occur when we request the same host directly from ingress istio proxy (aka bypassing L1). Only when we request them thru edge proxy. The normal, non-long lived connections of static pages work fine
The few things that came to mind are:
L1 somehow modifies the headers, which leads L2 proxy to drop the connection. I got the idea from (https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/level_two). However, i am not sure envoy allows to edit stream_error_on_invalid_http_message, and in addition, I don't think it actually solves the problem
L1 proxy introduces some timeouts that I am not aware of, and L1 after some time kills the long-lived connection. Though, I am pretty sure I have adjusted timeouts correctly, after reading: https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/edge. Also, as mentioned, the timeouts are not consistent, which makes me think that it isn't some timeout option.
My understandings might be wrong, as I am still starting with the envoy, so any criticism is welcomed!
My config is as follows:
config.yaml
node:
  cluster: proxy-cluster
  id: proxy1
dynamic_resources:
  cds_config:
    resource_api_version: V3
    path: /var/lib/envoy/cds.yaml
  lds_config:
    resource_api_version: V3
    path: /var/lib/envoy/lds.yaml

lds.yaml:
resources:
  - "@type": type.googleapis.com/envoy.config.listener.v3.Listener
    name: secure_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 443 }
    listener_filters:
      - name: envoy.filters.listener.tls_inspector
        typed_config: {}
    filter_chains:
      - filter_chain_match:
          server_names: [ "engine.ubnetdef.org" ]
          destination_port: 443
        transport_socket:
          name: envoy.transport_sockets.tls
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
            common_tls_context:
              tls_certificate_sds_secret_configs:
                name: engine
                sds_config:
                  resource_api_version: V3
                  path: /var/lib/envoy/sds-engine.yaml
        filters:
          - name: envoy.filters.network.http_connection_manager
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
              common_http_protocol_options:
                idle_timeout: 7200s
              http2_protocol_options:
                max_concurrent_streams: 100
                initial_stream_window_size: 65536 # 64 KiB
                initial_connection_window_size: 1048576 # 1 MiB
              stream_idle_timeout: 0s
              request_timeout: 0s
              codec_type: auto
              stat_prefix: ingress_http
              use_remote_address: true
              route_config:
                name: local_route
                virtual_hosts:
                  - name: engine
                    domains: ["engine.ubnetdef.org"]
                    routes:
                      - match:
                          prefix: "/"
                        route:
                          timeout: 0s
                          idle_timeout: 0s
                          cluster: kubernetes

              http_filters:
                - name: envoy.filters.http.router

cds.yaml:
resources:
  - "@type": type.googleapis.com/envoy.config.cluster.v3.Cluster
    name: kubernetes
    connect_timeout: 20s
    type: static
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options:
            initial_stream_window_size: 65536 # 64 KiB
            initial_connection_window_size: 1048576 # 1 MiB
    lb_policy: round_robin
    load_assignment:
      cluster_name: kubernetes
      endpoints:
        - lb_endpoints:
            - endpoint:
                health_check_config:
                  port_value: 30080
                address:
                  socket_address:
                    address: 192.168.8.200
                    port_value: 30080
            - endpoint:
                health_check_config:
                  port_value: 30080
                address:
                  socket_address:
                    address: 192.168.8.201
                    port_value: 30080
            - endpoint:
                health_check_config:
                  port_value: 30080
                address:
                  socket_address:
                    address: 192.168.8.202
                    port_value: 30080

Envoy logs, at the point when stream failed(running with -l trace, since -l debug did not output anything at that time interval):
[2021-04-26 22:06:27.133][20606][debug][main] [external/envoy/source/server/server.cc:209] flushing stats
[2021-04-26 22:06:28.165][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.165][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.165][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.165][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 13880
[2021-04-26 22:06:28.165][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.165][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 13880 bytes
[2021-04-26 22:06:28.165][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 13880 bytes
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:957] [C5] about to send frame type=8, flags=0
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:979] [C5] send data: bytes=13
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C5] writing 13 bytes, end_stream false
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:886] [C5] sent frame type=8
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 2
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:67] [C5] write returns: 13
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 2513
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 2513 bytes
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.166][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.166][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 2513 bytes
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 2
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.166][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 8
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 2776
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 2776
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 2789
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 6940
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 26385 bytes
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.167][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=3043 padding_length=0
[2021-04-26 22:06:28.167][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=3043 end_stream=false)
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 3050 bytes, end_stream false
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 26385 bytes
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 2
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 3058
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 16656
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.167][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.167][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 33312 bytes
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.168][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.168][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 33312 bytes
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:957] [C5] about to send frame type=8, flags=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:979] [C5] send data: bytes=13
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C5] writing 13 bytes, end_stream false
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:886] [C5] sent frame type=8
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:67] [C5] write returns: 13
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 3371
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 3371 bytes
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=10828 padding_length=0
[2021-04-26 22:06:28.168][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=10828 end_stream=false)
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 10836 bytes, end_stream false
[2021-04-26 22:06:28.168][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 3371 bytes
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.168][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 10852
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 9716
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 11104
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 26372 bytes
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.169][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 26372 bytes
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:957] [C5] about to send frame type=8, flags=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:979] [C5] send data: bytes=13
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C5] writing 13 bytes, end_stream false
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:886] [C5] sent frame type=8
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:67] [C5] write returns: 13
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 11979
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 11979 bytes
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.169][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=5556 padding_length=0
[2021-04-26 22:06:28.169][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=5556 end_stream=false)
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 5564 bytes, end_stream false
[2021-04-26 22:06:28.169][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 11979 bytes
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.169][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 5580
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 16656
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 5552
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 27760 bytes
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.170][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 27760 bytes
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:957] [C5] about to send frame type=8, flags=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:979] [C5] send data: bytes=13
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C5] writing 13 bytes, end_stream false
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:886] [C5] sent frame type=8
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:67] [C5] write returns: 13
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 15854
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 15854 bytes
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=16384 padding_length=0
[2021-04-26 22:06:28.170][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=16384 end_stream=false)
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 16392 bytes, end_stream false
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=10819 padding_length=0
[2021-04-26 22:06:28.170][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=10819 end_stream=false)
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 10827 bytes, end_stream false
[2021-04-26 22:06:28.170][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 15854 bytes
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.170][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 16384
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 10843
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C5] socket event: 3
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C5] write ready
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:585] [C5] read ready. dispatch_buffered_data=false
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:24] [C5] read returns: 259
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/raw_buffer_socket.cc:38] [C5] read error: Resource temporarily unavailable
[2021-04-26 22:06:28.171][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:657] [C5] dispatching 259 bytes
[2021-04-26 22:06:28.171][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:754] [C5] about to recv frame type=0, flags=0
[2021-04-26 22:06:28.171][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:779] [C5] recv frame type=0
[2021-04-26 22:06:28.171][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:1594] [C5] track inbound frame type=0 flags=0 length=250 padding_length=0
[2021-04-26 22:06:28.171][20617][trace][http] [external/envoy/source/common/http/conn_manager_impl.cc:1464] [C4][S12597774770368222501] encoding data via codec (size=250 end_stream=false)
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:470] [C4] writing 256 bytes, end_stream false
[2021-04-26 22:06:28.171][20617][trace][http2] [external/envoy/source/common/http/http2/codec_impl.cc:691] [C5] dispatched 259 bytes
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:547] [C4] socket event: 2
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/common/network/connection_impl.cc:656] [C4] write ready
[2021-04-26 22:06:28.171][20617][trace][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:254] [C4] ssl write returns: 256
[2021-04-26 22:06:32.137][20606][debug][main] [external/envoy/source/server/server.cc:209] flushing stats

Any ideas on what I might be missing are appreciated!
Perhaps telling the envoy to not modify traffic, and sending as is? Is there such an option, even if it is not efficient?
Envoy version: 1.18.2
[optional Relevant Links:]
https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/edge
https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/level_two

I do not see anything interesting in the attached log. It looks like Envoy proxying data normally. Are you sure these connection resets are caused by Envoy? You may want to collect TCP dump as well, to see if it gives any clues.

The TCP from L1 to L2 just has a continuous TCP stream(any ideas, on how I could get more insight into what is going on in there?)

The Connection from the client to L1 is encrypted, after some data there are retransmissions:

What happens after retransmissions? Do you see reset from L1? So far it looks like the issue is between L1 and client.

The way server-to-client stream works in our environment is it sends updates every 20 seconds,
Those are the only packets that were captured between the client, and L1 at the time of reset. On the client-side chrome reports net::ERR_CONNECTION_RESET after the 3rd retransmission packet (attached are the timestamps for Client and L1).

Hmm, I'm out of suggestions. You will need to diagnose the reason for network connection breaking down between Envoy and client. So far it does not look an Envoy problem.

I did not consider that there might be other networking issues, but I did forget to mention that the connection to L2 was accessed thru VPN, which put me on a local logical network as an L2 device, and L1 was accessed publically, which made the TCP connection for the client to L2 run thru our edge firewall directly.
After testing the client connection to L2 from VPN, the issue seemed to go away, which leads me to believe that there might be some setting in firewalls causing the issue.
I have retested and reproduced my previous results, envoy doesn't send those reset packets, yet the client sees them, which makes me think more that it is some sort of firewall up the stream.
Thanks for taking your time, and for your perspective.
Also, do you know if the envoy employs features that would allow long-lived server-to-client TCP sessions to overcome commonly implemented firewall TCP resets methods (I am not aware of any such methods, but if the envoy has some methods to overcome similar issues, please let me know)

Resolved


text:
AccessLogManagerImplTest.ReopenRetry is flaky

This test failed on linux_x64 coverage for me in a recent change (that only affected docs).
https://dev.azure.com/cncf/envoy/_build/results?buildId=102214&view=logs&jobId=bbe4b42d-86e6-5e9c-8a0b-fea01d818a24&j=bbe4b42d-86e6-5e9c-8a0b-fea01d818a24&t=e00c5a13-c6dc-5e9a-6104-69976170e881
[ RUN      ] AccessLogManagerImplTest.ReopenRetry
test/common/access_log/access_log_manager_impl_test.cc:447: Failure
Expected equality of these values:
  0UL
    Which is: 0
  store_.gauge("filesystem.write_total_buffered", Stats::Gauge::ImportMode::Accumulate) .value()
    Which is: 12
Stack trace:
  0x7ba6bc: (unknown)
  0x7f87342e23bd: testing::internal::HandleSehExceptionsInMethodIfSupported<>()
  0x7f87342c8d9e: testing::internal::HandleExceptionsInMethodIfSupported<>()
  0x7f87342b028d: testing::Test::Run()
  0x7f87342b0dde: testing::TestInfo::Run()
... Google Test internal frames ...

[2022-02-23 00:42:28.952][2707][debug][main] [source/common/access_log/access_log_manager_impl.cc:18] destroying access logger foo
[2022-02-23 00:42:28.953][2707][debug][main] [source/common/access_log/access_log_manager_impl.cc:21] destroyed access loggers
[  FAILED  ] AccessLogManagerImplTest.ReopenRetry (17 ms)

It looks like this test was recently added by @pyrl247 in #19714.
@pyrl247 Can you please investigate?

FYI: @mattklein123 who reviewed #19714.

Sorry,I just noticed. I think see what the problem is.I will fix this today.


text:
active_connections counter in connection limit filter can underflow

Title: active_connections counter in connection limit filter can underflow
Description:
When both the local rate limit filter and the connection limit filter are used, and local rate limit filter is applied before the connection limit filter, connections rejected by the local rate limit filter can cause the active connection counter in the connection limit filter to be decremented without incrementing the counter, and thus, cause the counter to underflow, and causing the connection limit filter to reject further incoming connections.
When we encountered this issue, the Envoy proxy closed incoming connections immediated without trying to establish connections to the backends. From the metrics, we found that active_connections counter from the connection limit filter had extremely high number as below.
connection_limit.<listener_name>.active_connections: 18446744073683508455
connection_limit.<listener_name>.limited_connections: 82560385
local_rate_limit.<listener_name>.rate_limited: 26043161

In the above numbers <active_connections> + <rate_limited> = 2^64, indicating that the active_connections counter was decremented by the number of rate limited connnections. It appears that Filter::onNewConnection is not called when a connection is rejected by local_rate_limit filter, but Filter::onEvent is called when the connection is closed, and thus active_connections counter can be decreased even when it is 0.
Repro steps:

Configure a listener with both local rate limit filter and connection limit filter.
Run a webserver to use it as the backend for the cluster. I used python http.server

$ python3 -m http.server 11080
Serving HTTP on 0.0.0.0 port 11080 (http://0.0.0.0:11080/) ...
127.0.0.1 - - [25/Jul/2022 19:33:07] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [25/Jul/2022 19:33:07] "GET / HTTP/1.1" 200 -

Send multiple requests in parallel to trigger local rate limit. I used hey(https://github.com/rakyll/hey)

$ hey -n 100 -c 1 http://127.0.0.1:10080

Summary:
  Total:        0.0414 secs
  Slowest:      0.0085 secs
  Fastest:      0.0012 secs
  Average:      0.0049 secs
  Requests/sec: 2417.4965

  Total data:   1287 bytes
  Size/request: 429 bytes

...

Status code distribution:
  [200] 3 responses

Error distribution:
  [89]  Get "http://127.0.0.1:10080": EOF
  [1]   Get "http://127.0.0.1:10080": read tcp 127.0.0.1:36730->127.0.0.1:10080: read: connection reset by peer
  [1]   Get "http://127.0.0.1:10080": read tcp 127.0.0.1:36734->127.0.0.1:10080: read: connection reset by peer
  [1]   Get "http://127.0.0.1:10080": read tcp 127.0.0.1:36746->127.0.0.1:10080: read: connection reset by peer
  [1]   Get "http://127.0.0.1:10080": read tcp 127.0.0.1:36760->127.0.0.1:10080: read: connection reset by peer
  [1]   Get "http://127.0.0.1:10080": read tcp 127.0.0.1:36772->127.0.0.1:10080: read: connection reset by peer
  [1]   Get "http://127.0.0.1:10080": read tcp 127.0.0.1:36818->127.0.0.1:10080: read: connection reset by peer
  [1]   Get "http://127.0.0.1:10080": read tcp 127.0.0.1:36838->127.0.0.1:10080: read: connection reset by peer
  [1]   Get "http://127.0.0.1:10080": read tcp 127.0.0.1:36872->127.0.0.1:10080: read: connection reset by peer

Check stats. active_connections count shows that the counter underflowed

curl -s http://localhost:9901/stats|egrep "connection_limit|local_rate_limit"
connection_limit.lhs-service.active_connections: 18446744073709551519
connection_limit.lhs-service.limited_connections: 0
local_rate_limit.lhs-service.rate_limited: 97

Config:
node:
    cluster: test-cluster
    id: test-id
admin:
  access_log_path: /tmp/admin_access.log
  address:
    socket_address:
      protocol: TCP
      address: 0.0.0.0
      port_value: 9901

static_resources:
  listeners:
  - name: sample-listener
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 10080
    filter_chains:
    - filters:
      - name: envoy.filters.network.local_ratelimit
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.local_ratelimit.v3.LocalRateLimit
          stat_prefix: lhs-service
          token_bucket:
            max_tokens: 3
            tokens_per_fill: 1
            fill_interval: "1s"
      - name: envoy.filters.network.connection_limit
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.connection_limit.v3.ConnectionLimit
          stat_prefix: lhs-service
          max_connections: 5
      - name: envoy.filters.network.tcp_proxy
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
          stat_prefix: lhs-service
          cluster: local-cluster
          max_connect_attempts: 1
  clusters:
  - name: local-cluster
    load_assignment:
      cluster_name: local-cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 11080

cc @mattklein123 @alyssawilk @delong-coder as code owners of the connection limiter

Dup of https://github.com/envoyproxy/envoy/issues/22127

authors: jparklab mattklein123 zuercher


text:
SPIFFE: support JWK set bundle format

Implement support for SPIFFE bundle format in the SPIFFE validator: https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md#4-spiffe-bundle-format
This allows de-coupling of the identity system from the xDS control plane, and the trust bundles can be updated independently.

WIP PR

authors: briansonnenberg kyessenov


text:
Envoy reports https traces to jaeger

Hello Guys,
is it possible to report https request by envoy? if so, could you please point me an example or some sample configurations? Thanks.

related jaeger setup issues: https://github.com/envoyproxy/envoy/issues/4963 https://github.com/envoyproxy/envoy/issues/5163. You will be able to find additional info, and people involved in Jaeger tracing there.

cc @objectiser, can you share your experience on this topic? Thanks very much.

@clyang82 Sorry haven't tried tracing https so not sure what the issue might be. Will try taking a look when I can some free cycles, but not sure when at the moment.

@objectiser Thanks for your time. Here is my steps:

install istio
kubectl create secret tls nginxsecret --cert /etc/certs/cert-chain.pem --key /etc/certs/key.pem
kubectl create configmap nginxconfigmap --from-file=samples/https/default.conf
kubectl apply -f <(bin/istioctl kube-inject -f samples/https/nginx-app.yaml)
curl -k https://my-nginx  --- it works now, but there is no trace data
modify my-nginx service port name to http-xxx and NodePort to ClusterIP - it is not working now.
I have tried to modify the envoy configure file to add certificate, but it cannot help

             "http_filters": {
                    "name": "envoy.router",
                    "tls_context": {
                      "common_tls_context": {
                        "tls_certificates": [
                          {
                            "certificate_chain": {
                              "filename": "/etc/certs/cert-chain.pem"
                            },
                            "private_key": {
                              "filename": "/etc/certs/key.pem"
                            }
                          }
                        ],
                      }
                    }

@clyang82 Ok glad you found the problem.


text:
[fuzz] fix invalid header related issues in fuzz tests

Commit Message: Cleanup fuzzed headers that are fed into methods whose incoming headers have already had checks performed by codecs or other callsites.
Additional Description:

conn_manager_impl_fuzz_test trips on a sanity check that the codecs validated the host header. Since we feed random fuzzed inputs to this method, we have to clean the input to be valid. The previous validation only removed whitespace, now it uses the same nghttp2_check_authority method.
codec_impl_fuzz_test trips on the use a host header in encodeHeaders from an http/1 input that has a missing host. At the point where the function is called, the request headers should already have a host header.

Testing: Added corpus entry for codec_impl that includes a request header without a host, and for conn_manager_impl that includes an invalid authority header.
Risk level: Low
Fixes:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21627
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21816
Signed-off-by: Asra Ali asraa@google.com

Also can you remind me where the host assertion comes from? We could weigh removing it - HTTP/0.9 doesn't require a host for example and we have to serialize raw HTTP to integration test it.

It trips on a missing host header for connect here: https://github.com/envoyproxy/envoy/blob/bad35c86655c77c155303c1c4b9f651f7de42714/source/common/http/http1/codec_impl.cc#L380. And I don't think we have a host assertion before that. Are CONNECT's without a host header allowed?

Connect isn't allowed without host - on ingress we would fail parsing.  I would like to gracefully handle the case where some filter screws up the host header - I'd added in throwing an exception like we do for missing method, but per Matt's point that doesn't work and you're removing it anyway.
I guess my thought is I'd like them all handled the same way, with graceful connection teardown "you did something wrong" rather than insist they be present even though intermediate filters could screw that up.
I'm cool with fuzzer fixes in the interim if it reduces noise, but could proper error handling for this and other expectations be part of the exception removal path?

Gotcha, thanks for the clarification!

even though intermediate filters could screw that up.
I'm cool with fuzzer fixes in the interim if it reduces noise, but could proper error handling for this and other expectations be part of the exception removal path?

I added proper error handling to inputs that may come from filters to the design overview of https://github.com/envoyproxy/envoy/issues/10878. It seemed like I will tackle it in two PRs: callback-only exceptions, and other exceptions like this that need to be replaced with proper error handling if they're hit. In the interim, I would at least like to add a comment/TODO reference for tracking in this PR. I feel like "TODO(10878): Add error handling for missing Host header" without any current handling at all is strange, wdyt?

Again I'm fine with interim fuzzer fixes, I was only really objecting to the API comments - if what we want long term is error handling rather than required field X (and we think it can't happen today apart from badly behaved filters) I'd be inclined to leave the API as-is and maybe TODO unwinding the fuzzer to fuzz once we have error handling for unexpected codec errors?

It seems that test/fuzz/utility.h is missing an #include "nghttp2/nghttp2.h".
Would also suggest to verify that Host header exists if connect is being used (so it will also be verified in after exceptions are removed) to https://github.com/envoyproxy/envoy/blob/941477afe7bee262392cf5b393fd33a8b6b8effc/source/common/http/http1/codec_impl.cc#L364
Other than that LGTM.

API comments fixed, added TODOs to add proper error handling for the missing connect/host header, since adding a throw would just be crashing

authors: adisuissa alyssawilk asraa


text:
stream_info: add downstream handshake completion timing

Signed-off-by: Paul Sohn paulsohn@google.com
Commit Message: Adds a downstreamTiming field to the connection-level streamInfo for when the TLS handshake completed for HTTP 1/2/3, for monitoring handshake latency.
Additional Description: Note that for HTTP/3 zero-RTT, the handshake may complete well into the life of the request, which is why this field is not copied into the stream-level streamInfo when a stream is created.
Risk Level: Low
Testing: Integration tests included in the PR.
Docs Changes: None
Release Notes: Added

@pksohn this needs some formatting fixes
you can use the diff/artefacts here to fix
https://dev.azure.com/cncf/envoy/_build/results?buildId=113538&view=results

@ggreenway the checks are finally passing for this PR. Any chance you might be able to take a look? Thanks!

@ggreenway @alyssawilk One thing I meant to ask about:
I removed the assertion that the handshake timestamp can only be written once, in this commit: https://github.com/envoyproxy/envoy/pull/22367/commits/61a8618bc246063886be9eba6ecbd4e19521b57e, upon discovering that the SslSocketTest::ClientSessionResumption... tests were failing due to SslSocket::onSuccess being called multiple times.
In practice do we actually expect SslSocket::onSuccess to be called multiple times for the same connection (e.g. on resumption)? If so, would we want the handshake-complete timestamp to be overwritten?

@ggreenway ping!

Would you be willing to add an access log formatter in source/common/formatter/substitutions_formatter.cc, at least for tcp-proxy access logs? I think this new field is generally useful so I'd like to make it more easily available.

Thanks -- I think I've added what you were suggesting.

@pksohn can you fix CI? Then I'll ping the reviewers again to try to make some progress.
/wait

/wait on coverage

/retest

@alyssawilk: there was a question above that we were hoping you could weigh in on (namely whether to move this metric into the SSL connection or leave it in downstream timing): https://github.com/envoyproxy/envoy/pull/22367#discussion_r941792000

I think you need to merge main to pick up #22792

authors: alyssawilk jmarantz phlax pksohn


text:
WIP: consistent admin

Signed-off-by: Alyssa Wilk alyssar@chromium.org

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

@jpsim @Augustyniak if I fix up the C++ tests to work sans admin, what do you folks think about landing this, vs switching only some of the CI bots to not include admin?

/retest

/retest

Probably want to change the title of the PR to remove "WIP"

/retest

authors: abeyad alyssawilk


text:
ext_authz: make the ext_authz filter a dual filter

This is a revival of #25535 with changes for previous review comments.
Risk level: low
Testing: integration tested
Docs changes: n/a
Release notes: makes the ext_authz filter a dual filter.
See also: #23071 (model), #10455

/assign @alyssawilk

/retest
/wait on CI
(please remove waiting label if retest fixes things, but looks like several are failing so I assum eit's real?)

/retest
AFAICT current failures are not related.

I think this needs some docs. What is the behavior when this is configured as an upstream filter? When would one configure this instead of a downstream auth filter?

We have a use case where ext_authz depends on some dynamic metadata to have been filled in by a previous filter in the filter chain (it's shipping that metadata off to the Check server), but that previous filter happens to depend on cluster/endpoint selection so it is an upstream filter. More broadly, one could imagine that the authz filter could ship cluster metadata to the Check server and would thus depend on cluster selection having happened already. The filter otherwise behaves identically to the downstream case, this is enabling the ability to put it on an upstream filter chain.

It seems like there should be some way to get it. Maybe look at how xfcc works, because that includes the cert in upstream requests.

At the moment, filters in an upstream filter chain do not have access to the downstream connection. XFCC is being implemented in the HttpConnectionManager which does have references to the downstream connection. I'm proposing disallowing this combination until the plumbing to enable this is present.
I'm happy to modify any additional docs as requested.

/wait on main merge and API warnings

Ok, with https://github.com/envoyproxy/envoy/pull/29488/files merged if you merge main  you should be ablle to have upstream authz tagged as alpha.  Also needs main merge

/retest

/retest

@ggreenway PTAL, thanks!
(AFAICT the presubmit failures are not related but they seem awfully flaky...)

authors: alyssawilk pianiststickman


text:
mobile: removing guarddog and watchdog

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/retest


text:
golang: add OnStreamComplete callback to mutate final metadata

As discussed from https://github.com/envoyproxy/envoy/pull/35595#issuecomment-2278413889, the AccessLogHandler::log is not designed for mutating the StreamInfo. It's recommended to use OnStreamComplete to do the final metadata management.

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

CC @doujiang24

I wanted to confirm whether or not this fixes #30859 as AccessLogger will access dynamicMetadata after WASM writes to it?

I wanted to confirm whether or not this fixes #30859 as AccessLogger will access dynamicMetadata after WASM writes to it?

No, this change is only about the Golang filter. If we want to support this in Wasm, we need to add OnStreamComplete callback in Wasm too.

Assigning @doujiang24 as codeowner
/assign @doujiang24

/assign-from @envoyproxy/envoy-maintainers

I wanted to confirm whether or not this fixes #30859 as AccessLogger will access dynamicMetadata after WASM writes to it?

No, this change is only about the Golang filter. If we want to support this in Wasm, we need to add OnStreamComplete callback in Wasm too.

@spacewander I am unsure if the onStreamComplete callback is already added in Wasm, as per envoy/http/filter.h and source/common/http/filter_manager.h. In this case, would moving the onStreamComplete call to after the destroyFilters() (which uses onDestroy) call in source/common/http/conn_manager_impl.cc provide the desired change? Thanks for the help!

I wanted to confirm whether or not this fixes #30859 as AccessLogger will access dynamicMetadata after WASM writes to it?

No, this change is only about the Golang filter. If we want to support this in Wasm, we need to add OnStreamComplete callback in Wasm too.

@spacewander I am unsure if the onStreamComplete callback is already added in Wasm, as per envoy/http/filter.h and envoy/source/common/http/filter_manager.h. In this case, would moving the onStreamComplete call to after the destroyFilters() (which uses onDestroy) call in envoy/source/common/http/conn_manager_impl.cc provide the desired change? Thanks for the help!

No, the wasm filter doesn't override the onStreamComplete so it's empty for Wasm.
Another idea is that you might create a wasm access logger before the real logger: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/wasm/v3/wasm.proto. I haven't tested it yet.

authors: adisuissa spacewander sunaydagli


text:
feat(logger): Add tlog for better test logging

What type of PR is this?
This is basically a new feature added to the current logging package.
What this PR does / why we need it:
This PR adds a better logging using package tlog provides helpers for adding timestamps to test logging.
Which issue(s) this PR fixes:

Fixes #3902

/retest

authors: Manoramsharma zirain

repo: envoyproxy/gateway


text:
docs: response override

Fixes #4658
Release Notes: No

thanks @zhaohuabing, can you also add this doc to docs/ and v1.2/

authors: arkodg zhaohuabing


text:
failed compile ...Validator.java file

I would to try your PGV plugin for validation protobuf messages (lang=java), but i can't compile my project. I faced with error:
[INFO] --- protobuf-maven-plugin:0.5.0:test-compile-custom (protoc-java-pgv) @ pgv-java-grpc ---
[INFO] Compiling 1 proto file(s) to C:\Users\Maksimov-DE\go\src\github.com\envoyproxy\protoc-gen-validate\java\pgv-java-grpc\target\generated-test-sources\protobuf\java-pgv
[ERROR] PROTOC FAILED: C:\Users\Maksimov-DE\go\src\github.com\envoyproxy\protoc-gen-validate\java\pgv-java-grpc\target\generated-test-sources\protobuf\java-pgv/io\envoyproxy\pgv\grpc\HelloValidator.java: No such file or directory
[ERROR] C:\Users\Maksimov-DE\go\src\github.com\envoyproxy\protoc-gen-validate\java\pgv-java-grpc\src\test\proto\hello.proto [0:0]: C:\Users\Maksimov-DE\go\src\github.com\envoyproxy\protoc-gen-validate\java\pgv-java-grpc\target\generated-test-sources\protobuf\java-pgv/io\envoyproxy\pgv\grpc\HelloValidator.java: No such file or directory
I try to run test from you repo - pgv-gava-jrpc with same error... Can you say, what i do wrong?

It looks like you are compiling on Windows. How are you building PGV?

Yes, I clone your project, and build PGV localy on Windows.

I think I fixed this in a PR #186 I'm working on. Since you have a local clone, can you verify by changing line 126 of templates/java/register.go to
fullPath := strings.Replace(javaPackage(f), ".", string(os.PathSeparator), -1)

https://github.com/envoyproxy/protoc-gen-validate/pull/186/files#diff-7861baaaa3aaaaead65cf98ebb8cc3e1R126

Now i clone rmichela:bugfix/java-multiple-files and have same error...
fullPath := strings.Replace(javaPackage(f), ".", string(os.PathSeparator), -1) - correctly now...

I haven't figered out yet, how to implement validatoin function to my own applycation (spring boot grpc hello server), but pgv-java-grpc module passed test successful now. I compiled PGV with corrected func JavaMultiFilePath in register.go like this -
func JavaMultiFilePath(f pgs.File, m pgs.Message) pgs.FilePath {
//fullPath := strings.Replace(javaPackage(f), ".", string(os.PathSeparator), -1)
fileName := classNameMessage(m) + "Validator.java"
filePath := pgs.JoinPaths(/*fullPath, */fileName)
return filePath
}
if you have some instructions how integrate validator in my application, I would be thanckfull!

@rmichela Any hints on how to integrate pgv into java application would be really helpful. I am able to successfully compile and it generated java-pgv packages. There is no clue on how to integrate with grpc service implementation.

https://github.com/envoyproxy/protoc-gen-validate/issues/202

@dimax0505 Can you try now with the latest -SNAPSHOT release?

https://oss.sonatype.org/content/repositories/snapshots/io/envoyproxy/protoc-gen-validate/ i add dependency from this repository, but have same error...

@dimax0505 did you do mvn clean compile -U to force update the snapshot?

yes:
[INFO] --- protobuf-maven-plugin:0.6.1:test-compile-custom (protoc-java-pgv) @ pgv-java-grpc ---
Downloading: https://oss.sonatype.org/content/repositories/snapshots/io/envoyproxy/protoc-gen-validate/protoc-gen-validate/0.1.0-SNAPSHOT/maven-metadata.xml
Downloading: https://repo.maven.apache.org/maven2/io/envoyproxy/protoc-gen-validate/protoc-gen-validate/0.1.0-SNAPSHOT/maven-metadata.xml
Downloading: http://repository.sonatype.org/content/repositories/releases/io/envoyproxy/protoc-gen-validate/protoc-gen-validate/0.1.0-SNAPSHOT/maven-metadata.xml
Downloading: https://oss.sonatype.org/content/repositories/snapshots/io/envoyproxy/protoc-gen-validate/protoc-gen-validate/0.1.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://oss.sonatype.org/content/repositories/snapshots/io/envoyproxy/protoc-gen-validate/protoc-gen-validate/0.1.0-SNAPSHOT/maven-metadata.xml (4 KB at 3.7 KB/sec)
Downloaded: https://oss.sonatype.org/content/repositories/snapshots/io/envoyproxy/protoc-gen-validate/protoc-gen-validate/0.1.0-SNAPSHOT/maven-metadata.xml (4 KB at 3.7 KB/sec)
Downloading: https://oss.sonatype.org/content/repositories/snapshots/io/envoyproxy/protoc-gen-validate/protoc-gen-validate/0.1.0-SNAPSHOT/protoc-gen-validate-0.1.0-20190526.214922-6.pom
Downloaded: https://oss.sonatype.org/content/repositories/snapshots/io/envoyproxy/protoc-gen-validate/protoc-gen-validate/0.1.0-SNAPSHOT/protoc-gen-validate-0.1.0-20190526.214922-6.pom (10 KB at 19.4 KB/sec)
Downloading: https://oss.sonatype.org/content/repositories/snapshots/io/envoyproxy/protoc-gen-validate/protoc-gen-validate/0.1.0-SNAPSHOT/protoc-gen-validate-0.1.0-20190526.214922-6-windows-x86_64.exe
Downloaded: https://oss.sonatype.org/content/repositories/snapshots/io/envoyproxy/protoc-gen-validate/protoc-gen-validate/0.1.0-SNAPSHOT/protoc-gen-validate-0.1.0-20190526.214922-6-windows-x86_64.exe (11446 KB at 1964.2 KB/sec)
[INFO] Compiling 1 proto file(s) to C:\Users\17318390\IdeaProjects\protoc-gen-validate\java\pgv-java-grpc\target\generated-test-sources\protobuf\java-pgv
[ERROR] PROTOC FAILED: C:\Users\17318390\IdeaProjects\protoc-gen-validate\java\pgv-java-grpc\target\generated-test-sources\protobuf\java-pgv/io\envoyproxy\pgv\grpc\asubpackage\HelloRequestValidator.java: No such file or directory
[ERROR] C:\Users\17318390\IdeaProjects\protoc-gen-validate\java\pgv-java-grpc\src\test\proto\hello.proto [0:0]: C:\Users\17318390\IdeaProjects\protoc-gen-validate\java\pgv-java-grpc\target\generated-test-sources\protobuf\java-pgv/io\envoyproxy\pgv\grpc\asubpackage\HelloRequestValidator.java: No such file or directory
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13.246 s
[INFO] Finished at: 2019-05-27T09:13:19+03:00
[INFO] Final Memory: 15M/209M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.xolstice.maven.plugins:protobuf-maven-plugin:0.6.1:test-compile-custom (protoc-java-pgv) on project pgv-java-grpc: protoc did not exit cleanly. Review output for more information. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

There is a forward slash between java-pgv and io/envoyproxy. Is that what is causing the problem?

yes... but now, i change com.google.protobuf:protoc:3.6.1 to 3.8.0 and error disappear... i don't undestand it... I will try test it on my app in local network, one qwestion -  were artefacts in repo https://oss.sonatype.org/content/repositories/snapshots/io/envoyproxy/protoc-gen-validate been generated from master branch of current project?

Yes. Everything is built from master.

i change com.google.protobuf:protoc:3.6.1 to 3.8.0 and error disappear

I have no way to reproduce your problem, but the fact that upgrading protoc fixed your build makes me think this is a bug in protoc and not PGV. @rodaine, what do you think?

@keith Are you also having trouble building on Windows with protoc 3.6.1?

@rodaine, what do you think?

After fixing the slash issue, what was the error reported by 3.6.1, @dimax0505?

@rodaine, what do you think?

After fixing the slash issue, what was the error reported by 3.6.1, @dimax0505?

sorry, i don't clear undestend your question...
i try two way - first - https://github.com/envoyproxy/protoc-gen-validate/issues/191#issuecomment-492941643 - i change file templates/java/register.go, and now it work in my local project.
second - i change 3.6.1 to 3.8.0...
if you talk about  snapshot-0.2.0 - i don't try it yet...

second - i change 3.6.1 to 3.8.0

Did this fix your problem?

yes, thanks, i closing issue...

authors: dimax0505 rmichela rodaine skyrocknroll

repo: envoyproxy/protoc-gen-validate


text:
Add missing go_package for gogoproto

The copy of gogoproto is missing option go_package. This will cause generated code got wrong import path in Golang.
import (
	_ "gogoproto"
)

And the Go compiler will complain about cannot find the gogoproto package.
After fixing, the import path will look like this
import (
	_ "github.com/gogo/protobuf/gogoproto"
)

Then we're good to go.

Thanks!

authors: XSAM rodaine


text:
modification to support new GA SDK to support new languages

If you want to integrate this upgrade

Hi @normyx
Thanks for your PR! Before we merge, just two questions.
It looks like you added a few commands:
{
...
+          command: this.translate("CMD_SWITCH_OFF"),
+          description : this.translate("CMD_SWITCH_OFF_DESCRIPTION"),
+          callback : 'cmd_asstnt_switch_off',
+        },
+        {
+          command: this.translate("CMD_PAGE_INCR"),
+          description : this.translate("CMD_PAGE_INCR_DESCRIPTION"),
+          callback : 'cmd_asstnt_page_incr',
+        },
...

et.al.

Are those RPi specific? (You have tested this on a what OS/HW version?)
What does the "page increment` do? (Does it depend on something else?)

Thanks again.

Hi,
I confirm it is a mistake in the PR, this was a specific implem from my side, for Raspi.

@normyx
I'll integrate this manually. How does the module work for you with the new GA SDK?
Feel free to post in our issues if you have any.
PS. I have also opened a dev branch you can send future PRs to.

repo: eouia/MMM-Assistant


text:
Folders from "Shared with me" are exported thru "Export conversation without attachments" at the bottom of the conversations panel

EPAM AI DIAL chat version
0.6.0
What happened?

By user1 create some hierarchy to share folder, chat
By user2 click on the link to have "Shared with me"
By user2 create some folders/chats in Pinned/Today
By user2 export the whole structure using the export button at the bottom of the chat panel
By user3 import the structure and check that "Shared with me" is not imported; only chats from Pinned/Today are imported -> chats from Shared with me are not imported (ok), but folder yes -> bug

Note: after browser refresh these folders disappear as they are empty
Note: seems the same issue could be for prompts, please, re-check.

Expected result: "Shared with me" structure is NOT exported thru "Export conversation without attachments" button at the bottom of the conversations panel
Confidential information

[X] I confirm that do not share any confidential information

Issue is fixed , not reproducible any more on staging 0.14.0

authors: VolhaBazhkova YauheniyaH

repo: epam/ai-dial-chat


text:
Vite.js failed to transpile @juggle/resize-observer

Hi, I would like to switch my project to vite.js instead of react-scripts but I can't because of a dependency of ketcher-react.
Steps to Reproduce

Replace react-scripts by vite.js
Configure vite

export default defineConfig(({ mode }) => {
  return {
    plugins: [react(), viteTsconfigPaths(), svgrPlugin()],
    optimizeDeps: {
      esbuildOptions: {
        // Node.js global to browser globalThis
        define: {
          global: 'globalThis',
        },
        // Enable esbuild polyfill plugins
        plugins: [
          NodeGlobalsPolyfillPlugin({
            buffer: true,
            process: true // -> needed for some of my external packages
          }),
          NodeModulesPolyfillPlugin(),
        ],
      },
    },
    build: {
      sourcemap: false,
      rollupOptions: {
        cache: false,
        plugins: [
          // Enable rollup polyfills plugin
          // used during production bundling
          rollupNodePolyFill(),
        ],
      },
    },
    server: {
      port: 3000,
    },
  };
});

Start vite and open http://localhost:3000
Open the error console

Actual behavior
Uncaught SyntaxError: Identifier 'process' has already been declared (at ketcher-react.js?v=c1ad07e1:7821:5)

// node_modules/@juggle/resize-observer/lib/utils/process.js
var process; // <- process is already defined. process seems to be declare as a global var.
var init_process2 = __esm({
  "node_modules/@juggle/resize-observer/lib/utils/process.js"() {
    init_process();
    init_buffer();
    init_hasActiveObservations();
    init_hasSkippedObservations();
    init_deliverResizeLoopError();
    init_broadcastActiveObservations();
    init_gatherActiveObservationsAtDepth();
    process = function() {
      var depth = 0;
      gatherActiveObservationsAtDepth(depth);
      while (hasActiveObservations()) {
        depth = broadcastActiveObservations();
        gatherActiveObservationsAtDepth(depth);
      }
      if (hasSkippedObservations()) {
        deliverResizeLoopError();
      }
      return depth > 0;
    };
  }
});

Desktop (please complete the following information):

OS: macOS 13.2.1
Browser: chrome
Version: Version 111.0.5563.64

Ketcher version
2.7.2

Hi @ben-ikt thanks for reaching out! We are currently investigating using vite.js as the build tool for the project. You can follow this issue to check progress with that: https://github.com/epam/ketcher/issues/2411

Hi @KonstantinEpam23, here is how I patch @juggle/resize-observer via an esbuild plugin.
/**
 * HACK @juggle/resize-observer/lib/utils/process.js used by ketcher-react
 * 'var process' create a conflict with NodeGlobalsPolyfillPlugin({ process: true })
 */
const ketcherReactTranspile = () => {
  return {
    name: 'ketcher-react-transpile',
    setup(build) {
      build.onLoad({ filter: /@juggle\/resize-observer\/lib\/utils\/process.js/ }, async (args) => {
        const source = await readFile(args.path, 'utf8');
        const hackedSource = source
          .replace('var process =', 'var processTask =')
          .replace('export { process }', 'export { processTask as process }');
        return { contents: hackedSource };
      });
    },
  };
};

And in my vite.config.js
optimizeDeps: {
      esbuildOptions: {
        // Node.js global to browser globalThis
        define: {
          global: 'globalThis',
        },
        // Enable esbuild polyfill plugins
        plugins: [
          ketcherReactTranspile(),
          NodeGlobalsPolyfillPlugin({
            process: true,
          }),
          NodeModulesPolyfillPlugin(),
        ],
      },
    },

repo: epam/ketcher


text:
This fixes issue #58.

I had to make some local modifications to get the unit tests to work, but those are for another issue.
Let me know if this works, and thank you!

Improved this behaviour as a part of #82

authors: printsev tballison

repo: epam/parso


text:
Build process

Dune tool integration
https://dune.build

In Makefile
https://github.com/epatrizio/comp2mzam/blob/main/Makefile
OCaml compilation : ocamlc VS ocamlopt

license: Unlicense