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
feat: add compression handler to server handler #5433
Conversation
50cb4f1
to
fb970c6
Compare
✅ Deploy Preview for openpolicyagent ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for openpolicyagent ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Signed-off-by: burnerlee <avi.aviral140@gmail.com>
Signed-off-by: burnerlee <avi.aviral140@gmail.com>
cd9f2f0
to
898f461
Compare
reader := bytes.NewReader([]byte(act)) | ||
gzreader, _ := gzip.NewReader(reader) | ||
output, _ := io.ReadAll(gzreader) | ||
act = string(output) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This adjusts the test, but if you're running opa with
opa run --server --log-level debug
will it spill gzip binary data into your logs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes if the client sends the request with Accept-Encoding
header set to gzip, then it would do so. But isn't it the intended behaviour?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😅 spewing binary data into the logs is not the intended behaviour. For the metrics endpoint, we'll log "binary payload" instead -- this is what the test was about. For the data endpoints, I think we should include the decompressed data in the debug logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose decompressing what we've previously compressed to log it is also kind of weird, and an indicator that logging should be wired differently. 🤔
@@ -71,6 +71,7 @@ require ( | |||
github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect | |||
github.com/golang/snappy v0.0.4 // indirect | |||
github.com/google/flatbuffers v1.12.1 // indirect | |||
github.com/gorilla/handlers v1.5.1 // indirect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that these were recently archived, I'm wondering what other options would be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about just include the handlers internally I see the implementation of gorilla/handlers is not dependent on another gorilla package https://github.com/gorilla/handlers/blob/v1.5.1/compress.go#L63
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's a possibility. Sorry there are so many things in flight here right now, please note #5483.
🧹 cleaning out open PRs. Feel free to re-open if you happen to get back to this. 😃 |
I think this should wait until gorilla/mux has been replaced, #5483 |
Signed-off-by: burnerlee avi.aviral140@gmail.com
resolves #5310
Feature addition
This PR adds
CompressionHandler
to the server initialised in server.go file.Also, it updates the test - TestRequestLogging to enable checking for gzip compression. If
gzip
is specified asAccept-Encoding
header value, then a gzip compressed payload is returned and the response hasContent-Encoding
header set togzip
. We verify this, and verify the compressed payload by decompressing it manually and matching it to the original string.