You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm a maintainer of Traefik, which rely on klauspost/compress for its Compress middleware.
We recently updated Traefik to go1.20, which brought the support for 103 Early Hints status code, and more generally 1xx status codes, as per the go1.20 release note:
We gathered feedback on that feature and we identified a bug when using the gzip compression middleware.
Here is a sample curl trace of response with Early Hints, with and without gzip compression:
Without gzip:
❯ curl -vvv -H "Content-Type: text/html" http://whoami:8180
* Trying 127.0.0.1:8180...
* Connected to whoami (127.0.0.1) port 8180 (#0)
> GET / HTTP/1.1
> Host: whoami:8180
> User-Agent: curl/7.88.1
> Accept: */*
> Content-Type: text/html
>
< HTTP/1.1 103 Early Hints
< Link: </style.css>; rel=preload; as=style
< Link: </script.js>; rel=preload; as=script
< Vary: Accept-Encoding
< HTTP/1.1 404 Not Found
< Content-Length: 1103
< Content-Type: text/html; charset=utf-8
< Date: Tue, 02 May 2023 08:06:43 GMT
< Link: </style.css>; rel=preload; as=style
< Link: </script.js>; rel=preload; as=script
< Link: </style2.css>; rel=preload; as=style
< Link: </script2.js>; rel=preload; as=script
<
<!doctype html>
* Connection #0 to host whoami left intact
[... rest of the response body is omitted from the example ...]
With gzip:
❯ curl -vvv --compressed -H "Content-Type: text/html" http://whoami:8180
* Trying 127.0.0.1:8180...
* Connected to whoami (127.0.0.1) port 8180 (#0)
> GET / HTTP/1.1
> Host: whoami:8180
> User-Agent: curl/7.88.1
> Accept: */*
> Accept-Encoding: deflate, gzip, br, zstd
> Content-Type: text/html
>
< HTTP/1.1 103 Early Hints
< Content-Encoding: gzip
< Content-Type: text/html; charset=utf-8
< Date: Tue, 02 May 2023 08:07:07 GMT
< Link: </style.css>; rel=preload; as=style
< Link: </script.js>; rel=preload; as=script
< Link: </style2.css>; rel=preload; as=style
< Link: </script2.js>; rel=preload; as=script
< HTTP/1.1 200 OK
< Content-Encoding: gzip
< Content-Type: text/html; charset=utf-8
< Date: Tue, 02 May 2023 08:07:07 GMT
< Link: </style.css>; rel=preload; as=style
< Link: </script.js>; rel=preload; as=script
< Link: </style2.css>; rel=preload; as=style
< Link: </script2.js>; rel=preload; as=script
< Content-Length: 852
<
<!doctype html>
* Connection #0 to host whoami left intact
[... rest of the response body is omitted from the example ...]
The first problem, that appears in the trace, is the duplication of headers.
The second problem, not shown in the trace, is that the informational headers are transmitted together with the gzip handler's response, so not as an interim response, which defeats the purpose of those headers.
All in all, if we did not overlook something, we think this should be fixed and we are going to open a PR for that.
Edit: I forgot to mention the third problem, which is that the status code is overwritten. The test server we used is replying at last with a 404 Not Found status code, but the gzip response is a 200 OK anyway in that case.
The text was updated successfully, but these errors were encountered:
Hello!
I'm a maintainer of Traefik, which rely on klauspost/compress for its Compress middleware.
We recently updated Traefik to go1.20, which brought the support for 103 Early Hints status code, and more generally 1xx status codes, as per the go1.20 release note:
We gathered feedback on that feature and we identified a bug when using the gzip compression middleware.
Here is a sample curl trace of response with Early Hints, with and without gzip compression:
Without gzip:
With gzip:
The first problem, that appears in the trace, is the duplication of headers.
The second problem, not shown in the trace, is that the informational headers are transmitted together with the gzip handler's response, so not as an interim response, which defeats the purpose of those headers.
All in all, if we did not overlook something, we think this should be fixed and we are going to open a PR for that.
Edit: I forgot to mention the third problem, which is that the status code is overwritten. The test server we used is replying at last with a
404 Not Found
status code, but the gzip response is a200 OK
anyway in that case.The text was updated successfully, but these errors were encountered: