gszr

{
	"name": "request-callout",
	"config": {
		"callouts": [
			{
				"name": "callout1",
				"request": {
					"url": "http://httpbin.org/anything",
					"by_lua": "kong.ctx.shared.callouts.callout1.caching.cache_key = kong.request.get_header('cache-key')"
				},

gszr

{
	"name": "request-callout",
	"config": {
		"callouts": [
			{
				"name": "c1",
				"request": {
					"url": "http://httpbin.org/uuid",
					"method": "GET"
				},

gszr

{
	"name": "request-callout",
	"config": {
		"callouts": [
			{
				"name": "callout1",
				"request": {
					"url": "http://httpbin.org/anything",
					"method": "GET"
				},

gszr

{
	"name": "request-callout",
	"config": {
		"callouts": [
			{
				"name": "callout1",
				"request": {
					"url": "http://httpbin.org/anything",
					"by_lua": "local body = kong.request.get_body() or {}; local id = body.id; if id then kong.ctx.shared.callouts.callout1.request.params.url = 'http://httpbin.org/anything/' .. id end",
					"method": "GET"

gszr

{
	"name": "request-callout",
	"config": {
		"callouts": [
			{
				"name": "callout1",
				"request": {
					"url": "http://httpbin.org/anything",
					"method": "GET",
					"query": {

gszr

worker_processes 1;

events{}

http {
	server {
		listen 10000 http2;

		location / {
			grpc_pass_header     Server;

gszr

After some more testing, I found no confirmation for the hypothesis below.

In testing, I instrumented Go pluginserver with the pprof library, as follows:

import (
  ...
	_ "net/http/pprof"
)
func main() {

gszr

\documentclass{article}
\usepackage{amsmath}
\usepackage{algorithm}
\usepackage{algpseudocode}

\begin{document}

\noindent
\begin{minipage}{0.45\linewidth}
    \raggedright

gszr

return {
   dependencies = {
      ansicolors = "1.0.2-3",
      binaryheap = "0.4-1",
      date = "2.2.1-1",
      etlua = "1.3.0-1",
      inspect = "3.1.3-0",
      ["kong-lapis"] = "1.16.0.1-1",
      ["kong-pgmoon"] = "1.16.2-1",
      loadkit = "1.1.0-1",

gszr

### Brief Intro

This answer will be a bit longer than I wanted it to be, but hopefully it clears
things up.

gRPC over HTTP/2 mandates "TE: trailers" (see [1] in references) since it
makes use of trailers - e.g., for the grpc-status and grpc-message headers
(it's useful to send a status at the end of the response rather than too early).

However, many client and server implementations do not fully handle trailers.