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

Feature/plugin request termination #2051

Closed
wants to merge 23 commits into from
Closed

Feature/plugin request termination #2051

wants to merge 23 commits into from

Conversation

pauldaustin
Copy link

Summary

Added a request termination plugin as described in issue #1279.

Full changelog

  • Implemented request-termination-plugin
  • Added 03-plugins/18-request-termination tests

Modified the schema validation to allow regex on numbers. For example
\\d{3} to only accept 3 digits in the number.
Add HTTP response for 503 Service unavailable. This will be used for a
new api-unavailable plugin that will send a 503 error. See #1279.
Added , to end of list
Changed to only log 500 errors
A new plug-in that allows a request to be terminated and a specified
HTTP status code and body returned.

This is useful to temporarily return a status page for a service. For
example if the service is unavailable due to scheduled maintenance.
Modified the schema validation to allow regex on numbers. For example
\\d{3} to only accept 3 digits in the number.
Add HTTP response for 503 Service unavailable. This will be used for a
new api-unavailable plugin that will send a 503 error. See #1279.
Added , to end of list
Changed to only log 500 errors
A new plug-in that allows a request to be terminated and a specified
HTTP status code and body returned.

This is useful to temporarily return a status page for a service. For
example if the service is unavailable due to scheduled maintenance.
git@github.com:pauldaustin/kong.git into
feature/plugin-request-termination

Conflicts:
	kong-0.9.8-0.rockspec
Copy link
Member

@Tieske Tieske left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thx for the PR, looks like you put some serious effort in it!

Few comments on a first glance, will have to look more in depth later.

local message = conf.message
if not status_code then
status_code = 503
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

common idiom in Lua for these 'default' checks is to do

local status_code = conf.status_code or 503

@@ -0,0 +1,3 @@
return {
tables = {"request_termination"}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this entire file is not needed, unless I'm missing something...

Kong will handle the plugin configuration including all fetching/storing of that data. The dao files (and also the migration files) are only required if the plugin has its own entities to store (for example the authentication plugins need to store credentials besides their own config)

so this can go, as well as the migrations files

@pauldaustin
Copy link
Author

Thanks for the comments, let me know if there is anything else.

Copy link
Member

@Tieske Tieske left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you rework the comments?

overall looks complete and well tested! 👍

@@ -4,7 +4,8 @@ local plugins = {
"galileo", "request-transformer", "response-transformer",
"request-size-limiting", "rate-limiting", "response-ratelimiting", "syslog",
"loggly", "datadog", "runscope", "ldap-auth", "statsd", "bot-detection",
"aws-lambda"
"aws-lambda",
"request-termination",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just combine those 2 lines

function RequestTerminationHandler:access(conf)
RequestTerminationHandler.super.access(self)

local status_code = conf.status_code or 503
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this 503 act as a default, hence it would be better placed in the schema.lua file

return {
no_consumer = true,
fields = {
status_code = { type = "number" },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can add the default 503 here

body = { type = "string" },
},
self_check = function(schema, plugin_t, dao, is_updating)
local errors
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this probably fails on the linter as an unused local variable, can be tested using make lint


if plugin_t.status_code then
if plugin_t.status_code < 100 or plugin_t.status_code > 599 then
return false, "status_code must be between 100..599"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this ought to be

return false, Errors.schema("status_code must be between 100..599")

same for the other errors below

@@ -141,7 +147,7 @@ local closure_cache = {}
--- Send a response with any status code or body,
-- Not all status codes are available as sugar methods, this function can be
-- used to send any response.
-- If the `status_code` parameter is in the 5xx range, it is expectde that the `content` parameter be the error encountered. It will be logged and the response body will be empty. The user will just receive a 500 status code.
-- If the `status_code` parameter is in the 5xx range, it is expected that the `content` parameter be the error encountered. For 500 errors it will be logged. The response body will be empty. The user will just receive a 500 status code.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment is not entirely clear imo. Maybe something like "Specifically for 500 errors: the message will be logged, but not passed in the response. The user will just get a 500 with standard message to prevent leaking sensitive information."

api_id = api6.id,
config = {
status_code=503,
body='{"code": 1, "message": "Service unavailable}'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is a missing quote at the end. Test passes, but is this intentional? if so a small comment as to why would make sense.

@pauldaustin
Copy link
Author

pauldaustin commented Mar 3, 2017 via email

@Tieske
Copy link
Member

Tieske commented Mar 6, 2017

@pauldaustin

For the constants.lua local_plugins. Would it not be better to have one per line with a trailing , . Then it would be easier to merge new changes?

yes please! 😄

local ok, err = v({status_code = "abcd"}, schema)
assert.same({status_code = "status_code is not a number"}, err)
local ok, error = v({status_code = "abcd"}, schema)
assert.same({status_code = "status_code is not a number"}, error)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please do not use error as a variable name. The common name for errors is err because error is a built in Lua function (which will be shadowed by the local declaration as applied above)

@pauldaustin
Copy link
Author

I noticed that 0.10 has been released.

Let me know if I need to merge from next or master into this branch to make it ready to merge again

@Tieske
Copy link
Member

Tieske commented Mar 12, 2017

rebase on next please

@pauldaustin
Copy link
Author

Let me know if there is anything else required

@Tieske Tieske added pr/ready (but hold merge) No more concerns, but do not merge yet (probably a conflict of interest with another PR or release) and removed pr/status/needs review labels Mar 16, 2017
@coopr
Copy link
Contributor

coopr commented Mar 23, 2017

Thanks @pauldaustin please stay tuned...

@Tieske
Copy link
Member

Tieske commented Mar 24, 2017

if anything, its gonna require docs on the getkong.org repo

@Tieske Tieske modified the milestones: 0.10.1, 0.10.2 Mar 27, 2017
Tieske added a commit that referenced this pull request Apr 4, 2017
* feat(plugin): request-termination

A new plug-in that allows a request to be terminated and a specified
HTTP status code and body returned.
This is useful to temporarily return a status page for a service. For
example if the service is unavailable due to scheduled maintenance.
@Tieske
Copy link
Member

Tieske commented Apr 4, 2017

merged through #2328 closing this.

@pauldaustin thank you!

@Tieske Tieske closed this Apr 4, 2017
@pauldaustin pauldaustin deleted the feature/plugin-request-termination branch May 18, 2017 22:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr/ready (but hold merge) No more concerns, but do not merge yet (probably a conflict of interest with another PR or release)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants