-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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(conf) configurable request body handling #2602
Conversation
ec7969d
to
925eb86
Compare
These tests passed, but yesterday's shenanigans broke the webhook delivery. https://travis-ci.org/Mashape/kong/builds/240117836 |
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.
One more thing: can we also open a PR against the 0.10
branch on getkong.org? The documentation section of the website is mostly copy-pasting from this default file, with some formatting tweaking.
@@ -70,6 +70,7 @@ local CONF_INFERENCES = { | |||
latency_tokens = {typ = "boolean"}, | |||
error_default_type = {enum = {"application/json", "application/xml", | |||
"text/html", "text/plain"}}, | |||
client_max_body_size = {typ = "string"}, |
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.
Seems like we are missing client_body_buffer_size
here
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.
since client_body_buffer_size
is a string, it isnt necessary to define it here. i can for explicitness if you like.
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, this is indeed for explicitness. All string
values are still listed here.
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.
Done
@@ -185,6 +185,27 @@ | |||
# `text/html`, `application/json`, and | |||
# `application/xml`. | |||
|
|||
#client_max_body_size = 0 # Defines the maximum request body size allowed |
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.
The Nginx default is 1m
. In the past, we've always respected Nginx's defaults when introducing new config variables that are just wrapping underplaying Nginx directives. Any reason for not doing so for this - sensitive - setting?
Additionally, when a config value is a 1-to-1 mapping of an Nginx directive, we also mention it in the description (controls the Nginx core module directive bearing the same name), and we include a note below with the link to the Nginx documentation (which is especially useful because it mentions size units like k
and m
that these directive use).
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.
Using the Nginx default (1m
) would be a breaking change, as we already define this as 0
in our template, hence the use of 0 here- my initial thought was to set it at 1m
, but this breaks tests and a number of expected behaviors. Would be happy to set this to 1m
in a separate change targetting 0.11 in a separate PR.
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.
Ah right, we have this hard-coded right now... We should probably introduce that change in 0.11 indeed. 0
is a dangerous default here, and contrary to our "least trust" policy introduced with 0.11 for saner/safer defaults.
@@ -84,6 +84,7 @@ server { | |||
access_log ${{PROXY_ACCESS_LOG}}; | |||
error_log ${{PROXY_ERROR_LOG}} ${{LOG_LEVEL}}; | |||
|
|||
client_body_buffer_size ${{CLIENT_BODY_BUFFER_SIZE}}; |
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.
we should also add them to the fixture Nginx template in specs/
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.
Done
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 think the fixtures/ max_body_size
is still hard-coded to 0
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.
Done-er :)
Docs PR in Kong/docs.konghq.com#437 |
2431145
to
08fba6d
Compare
Last minute second thought: I feel like we should just add a couple unit tests for those 2 new properties, to make sure the conf loader and the Nginx template both parse/set the values for those. This is mainly to ensure forward compatibility and set these properties in stone. |
808220d
to
bc27dea
Compare
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.
Cool!
bc27dea
to
960b7a9
Compare
Add directives for client_max_body_size and client_body_buffer_size, allowing users to work around request body read limitations without the need to use a custom Nginx config.
960b7a9
to
a84d701
Compare
Summary
Add directives for client_max_body_size and client_body_buffer_size, allowing users to work around request body read limitations without the need to use a custom Nginx config.
Note that we do not adjust or make configurable these values in the Admin API section, as there is currently no need.
Full changelog
client_max_body_size
andclient_body_buffer_size
directives and config notes.