Open pszeto opened 1 year ago
Zendesk ticket #1992 has been linked to this issue.
It looks like envoy sanitizes strong etag but preserves weak ones:
I've updated my app to return a weak etag and confirmed that was the cause:
curl with compression enabled
curl http://35.237.50.231/ -v -H "Accept-Encoding: gzip"
* Trying 35.237.50.231:80...
* Connected to 35.237.50.231 (35.237.50.231) port 80 (#0)
> GET / HTTP/1.1
> Host: 35.237.50.231
> User-Agent: curl/7.86.0
> Accept: */*
> Accept-Encoding: gzip
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< content-type: application/json
< etag: W/278eb1ee-99ec-4e8b-858b-d79b0f378b94
< x-auth-server: generic-server-7f9595855-9vs9p
< x-e-tag: 278eb1ee-99ec-4e8b-858b-d79b0f378b94
< date: Thu, 25 May 2023 13:44:41 GMT
< x-envoy-upstream-service-time: 6
< content-encoding: gzip
< vary: Accept-Encoding
< server: envoy
< transfer-encoding: chunked
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Failed reading the chunked-encoded stream
* Closing connection 0
The weak etag etag: W/278eb1ee-99ec-4e8b-858b-d79b0f378b94
is present in the response.
There is workaround but wondering if modify Envoy. Doesn't look if this is supported today in upstream.
According to the documentation, this is expected behavior. However, I'm not sure why this option exists or is the default.
A related thread that seems to discuss this is option but for another project is at: https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
This issue has been marked as stale because of no activity in the last 180 days. It will be closed in the next 180 days unless it is tagged "no stalebot" or other activity occurs.
Gloo Edge Version
1.14.x (latest stable)
Kubernetes Version
1.24.x
Describe the bug
Enabling compression on the gateway-proxy causes
etag
response headers to be removed in the client response.Steps to reproduce the bug
etag
header : https://github.com/pszeto/custom-auth-server/blob/master/deployment.yamlExpected Behavior
When curling the endpoint with compression disabled:
etag
header is present in the response. The logs shows this as well:Curl endpoint with compression enabled
-H "Accept-Encoding: gzip"
Logs shows the upstream is returning the
etag
header... but after it goes through thecompressor
filter. Theetag
is gone from the response.Additional Context
No response