-
Notifications
You must be signed in to change notification settings - Fork 24
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
[segmentation fault] response_payload_too_large #280
Comments
About body response parsing of PNG image =>
|
Hello, I think that it is definitely a check we can do, and it is very welcomed, especially on this memory-delicate wasm env. |
@M4tteoP Thanks for the PR, |
Good point. Apart from changes that are really proxy-wasm specific, the idea is to keep the basic conf file as much as possible aligned with the upstream Coraza one. We could move that idea upstream, but the config is meant to be customized for each deployment, so, by default, I would keep the least possible elements |
As JSON parsing is actived for request but not for response, I propose to change it. |
My 2p here: IMHO by default response body access should be disabled and the default should be raw. It is very extensive and if any should be only enabled carefuly because on every request we will be parsing a json. Same for request. Maybe we can discuss all this in a broader issue but having json by default sounds overkill given the experience of big memory consumption of coraza in wasm envs. |
I am facing to a segmentation fault on a simple GET request to an static PNG image of 3Mb (3731858 bytes)
The issue is reproductible on each request to this image.
As I import recommended-conf, I don't expect that png response are scaned, only text/plain text/html text/xml should be scan with the recommended conf.
Then the size of the response must not be an issue here, not more generated a segmentation fault.
Envoy configuration =>
Envoy log =>
The text was updated successfully, but these errors were encountered: