Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gziphttp: Support informational headers #814

Closed
rtribotte opened this issue May 2, 2023 · 0 comments · Fixed by #815
Closed

gziphttp: Support informational headers #814

rtribotte opened this issue May 2, 2023 · 0 comments · Fixed by #815

Comments

@rtribotte
Copy link
Contributor

rtribotte commented May 2, 2023

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:

The ResponseWriter.WriteHeader function now supports sending 1xx status codes

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant