reverse-proxy

It seems Caddy does not support wildcards/ expression matching in the reverse proxy's header_up.

For example this does not remove any headers:

header_up -X-SHIBBOLETH-*

This works as expected, but is limited in its use:

header_up -X-SHIBBOLETH-LOGIN

It'd be great if Caddy would support wildcards/ expression matching in the reverse proxy's header_up/ header_down.

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

2.5.1.0

Current Behavior

When calling kong.response.exit(), the function automatically sets the Content-Length header on the response even if the Transfer-Encoding header is present. This is in violation of RFC 7230 3.3.2:

A sender MUST NOT send a Content-

Improved or typo fixed.

这里有个例子，在指定的路由中启用 dubbo-proxy 插件:
curl http://127.0.0.1:9080/apisix/admin/**upstream**/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"nodes": {
"127.0.0.1:20880": 1
},
"type": "roundrobin"
}'

Solution

curl http://127.0.0.1:9080/apisix/admin/upstreams/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{

On contexts with many APIs and APIs calling other APIs in chains, having too many spans in the zipkin/jaeger dashboards may lead to a too complex usage of such dashboards and of not necessary big data volumes.

For Tyk's admin team, the steps representing the time spent in each Tyk middleware are much valuable.

But the upstream APIs teams just want to know the global time spent in Tyk interna

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
In some situation, like XiaoDu watch, which is sensitive to power consumption, may need to close the TCP-KeepAlive heartbeat message or increase the interval to send TCP-KeepAlive heartbeat message.
Mod_tcp_keepalive can help handle situ

Is your feature request related to a problem? Please describe.

As observed during #261, users can accidentally set timeouts inconsistently. A concrete example is that one can set a User facing timeout lower than any backend timeout, such that requests may fail early.

Describe the solution you'd like

We should provide some sanity checking to prevent unintended timeout behavior.

Is your feature request related to a problem? Please describe.

The hydrator have only Basic auth - see config: https://www.ory.sh/oathkeeper/docs/pipeline/mutator/#configuration-4, however for more flexibility, similiar pre-authorization mechanism could ba added as in the instropsection authenticator handler: https://www.ory.sh/oathkeeper/docs/pipeline/mutator/#configuration-4

**Descri

Currently we have a mix of:

• Out of memory error.
• Out of memory error
• out of memory error
• out of memory
• out of memory.
• out of memory [some context]

All these should be adjusted to use the same wording for consistency and it should also make the executable a little bit smaller 😄

We are running a tunnel which is being accessed by clients using WARP.

tunnel: TUNNEL_ID
credentials-file: /var/lib/cloudflared/TUNNEL_ID.json
warp-routing:
  enabled: true
grace-period: 120s

The grace period is configured to 120 seconds, however this appears to not be respected when sending SIGTERM to cloudflared. The tunnel is stopped after 30 seconds, even though a c

Ref discussions

• abhinavsingh/proxy.py#769 (comment)
• abhinavsingh/proxy.py#769 (comment)
• abhinavsingh/proxy.py#769 (comment)
• abhinavsingh/proxy.py#769 (comment)
• abhinavsingh/proxy.py#769 (comment)