profile
viewpoint
Enrique García Cota kikito @Kong Madrid, Spain http://kiki.to

kikito/bump.lua 587

A collision detection library for Lua

kikito/anim8 401

An animation library for LÖVE

kikito/ansicolors.lua 73

ANSI terminal color manipulation for Lua.

kikito/beholder.lua 72

Minimal observer pattern for Lua, with a couple twists

kikito/7-languages-in-7-weeks 58

My personal repo for 7LI7W exercises

bartbes/Class-Commons 39

An attempt at unifying lua class libraries to provide a common API.

kikito/Algorithm-Implementations 7

Share, discuss and improve algorithm implementations!

bartbes/Class-Commons-Tests 4

The tests for class commons implementations

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha 112e331b5be1279550804f2b40227c52a895b3d1

feat(*) introduce new traceid_byte_count conf Allows configuring the length in bytes of the ids generated by the plugin

view details

push time in an hour

Pull request review commentKong/kong-plugin-zipkin

feat(*) traceid bytes

 return {                              between = { 0, 1 } } },                                         { default_service_name = { type = "string", default = nil } },           { include_credential = { type = "boolean", required = true, default = true } },+          { traceid_bytes = { type = "integer", required = true, default = 16, one_of = { 8, 16 } } },

Done!

kikito

comment created time in an hour

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha cf8e37b68103626dce7fba39754bd5f046c2900d

chore(ci) pin the zipkin docker image (#76)

view details

Enrique García Cota

commit sha cd132601e7aef8b90c740ba1133cb8e6785b37ba

tests(*) take wait_for_* helper functions out of main loop This is to facilitate reusing on other loops

view details

Enrique García Cota

commit sha 7ef0ba752a544b58cbb764d0b51c2337ea6121f2

feat(*) introduce new traceid_byte_count conf Allows configuring the length in bytes of the ids generated by the plugin

view details

push time in 2 hours

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha cf8e37b68103626dce7fba39754bd5f046c2900d

chore(ci) pin the zipkin docker image (#76)

view details

Victor Soares

commit sha 78778a2236486e5c9256260ad65d10c1a4475a0a

Add support for W3C Trace Context

view details

Enrique García Cota

commit sha 85acbcc9ee82fb13e317e59eaad73a2c3481b76c

feat(handler) use the same header type which was received This change makes the plugin use whatever headers it received: if it received a B3 single header, it will pass on a B3 single header. If it receives a w3c header, it will pass on a w3c header. Note that the precedence has been changed from the original request for the case where several tracing headers are present simultaneously. Previously w3c would "win". The new precedence is b3 single > b3 > w3c

view details

Enrique García Cota

commit sha 815b0585afc91c7f34d0c8fce482e73e2e74e3d5

refactor(tracing_headers) rename parse_http_req_headers to tracing_headers Also, make tracing_headers.parse and tracing_headers.set .

view details

Enrique García Cota

commit sha e453cb61c39f058e147ab2489ed16860ae4a6a7e

feat(*) new header_type config option

view details

push time in 2 hours

delete branch Kong/kong-plugin-zipkin

delete branch : chore/ci-zipkin-version

delete time in 2 hours

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha cf8e37b68103626dce7fba39754bd5f046c2900d

chore(ci) pin the zipkin docker image (#76)

view details

push time in 2 hours

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha 57dc4612f5cd01f92846dc3d406769ee58484749

chore(ci) pin zipkin docker image version

view details

push time in 2 hours

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha c8052ae9b710c93236549670016e78d2fe06680e

chore(ci) pin zipkin docker image version

view details

push time in 2 hours

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha cff70d5ef2f286eb0fe1d1b830bc3df5f31e9fb9

chore(ci) make the zipkin version fixed in time

view details

push time in 2 hours

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha 64f0b8a43c436b794312aceed39520672fdba30f

chore(ci) make the zipkin version fixed in time

view details

push time in 2 hours

create barnchKong/kong-plugin-zipkin

branch : chore/ci-zipkin-version

created branch time in 3 hours

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha 7618ce922d958952b77af1aa9bd07479b6510af9

feat(*) new header_type config option

view details

push time in 4 hours

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha 985518b399963a86e99415deaa579d646450dea8

feat(*) new header_type config option

view details

push time in 7 hours

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha 4d0d54288aaacc804fc02f1ef8bf0faf04265564

feat(*) new header_type config option

view details

push time in 7 hours

PR closed Kong/kong-plugin-zipkin

Add support for W3C Trace Context

Accepts W3C Trace Context header and prioritizes the W3C Trace Context when present.

Emits W3C Trace Context header whether it was present on the incoming request or not. Would like feedback on whether this behavior should be configurable.

+186 -2

1 comment

3 changed files

victorNewRelic

pr closed time in 20 hours

pull request commentKong/kong-plugin-zipkin

Add support for W3C Trace Context

@victorNewRelic @ecourreges-orange @seh

I've added the features I mentioned in #75, so I will be closing this PR in favor of that one. Thanks a lot!

victorNewRelic

comment created time in 20 hours

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha af6164223ec6071ceabbbbf0f868d579e7af24d0

fix(handler) send TCP traffic correctly (#70) This commit fixes a problem when tracing TCP traffic, and adds an integration test which exercises that branch.

view details

Enrique García Cota

commit sha 47bb8c47332432c7f36febf71ec956e505ec9fc1

fix(*) store annotation times in microseconds Zipkin expects all timestamps & durations to be in microseconds. However the annotation timestamps we were sending were in seconds. There were several sources of confusion here: * ngx native functions (like ngx.now) are in seconds * kong annotations (like ctx.KONG_ACCESS_START_TIME) are in *milliseconds* (not microseconds). * possibly as a leftover from the opentracing origins, the plugin tried to transform all the timestamps into *seconds* on span creation, and then tried to ransform them into microseconds just before sending them to zipkin * The span abstraction attempts to call ngx.now() when it is missing some timestamps, further blurring things up. A quick fix to the problem would have been transforming the annotations from seconds to microseconds right before sending them to zipkin, just like it was being done with start_time and duration. But this approach would have required 3 extra table allocations per request. It would also remain a bit obscure because of the transformation to seconds first, and then into microseconds. Instead, the changes have been as follows: * The span abstraction is not able to "fill up" the timestamp and call ngx.now or something else. It expects all timestamps to be filled up, or it explodes (all of our timestamps were actually already filled in so this was dead code). * The span abstraction expects all times to be specified in *microseconds* already. To stress this out, all timestamps params have been renamed to _mu (for example start_timestamp becomes start_timestamp_mu). It also invokes math.floor on all timestamps because zipkin demmands integers. * The code in the handler is in charge of making the transformation into microseconds directly. * The reporter does not do any transformations on the timestamps

view details

Enrique García Cota

commit sha a19c4e633e5a31735836962141689194c1219ae0

fix(handler) don't assume ctx.KONG_* vars are set Fixes #68 The plugin assumed that certain variables such as `ctx.KONG_ACCESS_START` were always set. There are occasions where this isn't true, for example an auth plugin might skip the access phase altogether. The assumption provoked unwanted status reports. In #68 we can see an example in which the expected status code is 400 but because of this assumption we get 500 instead. This wraps all accesses to ctx.KONG_* with conditionals, using other values such as ngx_now_mu() if they are not present. There is some repetitiveness, but I resisted abstracting into a function to allow for short-circuiting the call to obtain the default value (i.e. to only call to ngx_now() when it was really needed).

view details

Enrique García Cota

commit sha 8efd4d1f88b6189b68c7bff7a6a5680d4a8ebf4a

chore(*) release 1.0.0

view details

Victor Soares

commit sha 233e0478032a451507a26574cbc3f474a88c8109

Add support for W3C Trace Context

view details

Enrique García Cota

commit sha 71869e1c689f7a27b914a1c92214c75890e37fe5

feat(handler) use the same header type which was received This change makes the plugin use whatever headers it received: if it received a B3 single header, it will pass on a B3 single header. If it receives a w3c header, it will pass on a w3c header. Note that the precedence has been changed from the original request for the case where several tracing headers are present simultaneously. Previously w3c would "win". The new precedence is b3 single > b3 > w3c

view details

Enrique García Cota

commit sha 07309bbed92d3d95a95c7787e66a816285bc584a

refactor(tracing_headers) rename parse_http_req_headers to tracing_headers Also, make tracing_headers.parse and tracing_headers.set .

view details

Enrique García Cota

commit sha 059d93764d2ee9f295561ed642de2c83f4a612d5

feat(*) new header_type config option

view details

push time in 21 hours

PR opened Kong/kong-plugin-zipkin

feat(*) w3c trace context with expanded tracing header control

This is an expansion over #69 . In addition of recognizing the W3C header tracing header, this PR adds a new option called header_type, with 4 possible values:

  • preserve: the plugin produces whatever format it receives on each request
  • b3-single: always use b3 single
  • b3: always use the "regular zipkin" headers, such as x-b3-traceid
  • w3c: use the w3c format

When options.header_type is set to anything other than preserve, and the trace headers don't match (for example the config is b3-single but we receive a w3c-trace-context) then we should send both kinds of headers. A warning is logged.

+1161 -515

0 comment

12 changed files

pr created time in a day

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha fa4269fa5fa25a4e5462090ae9c75ebd75f1bc30

refactor(tracing_headers) rename parse_http_req_headers to tracing_headers Also, make tracing_headers.parse and tracing_headers.set .

view details

Enrique García Cota

commit sha 1e441bb3a43f1a50c436fb9ed4e947a1699ebd19

feat(*) new header_type config option

view details

push time in a day

create barnchKong/kong-plugin-zipkin

branch : feat/w3c-trace-context

created branch time in a day

push eventKong/kong

Thijs Schreijer

commit sha 899e4e755fbac6c585f772c968bda146807d6d5a

fix(cmd) fix path order (#5729) The test mocks no longer get selected first because the wrong order is being set. fixes problem introduced in https://github.com/Kong/kong/commit/5e25921de2da56eeb45042c5f7c74822584b7ddf

view details

push time in 6 days

delete branch Kong/kong

delete branch : fix-paths

delete time in 6 days

PR merged Kong/kong

fix(cmd) fix path order

The test DNS mocks no longer get selected first because the wrong order is being set. In general the lua_package_path settings could no longer be used to override the LUA_PATH settings because precedence was set the wrong way around.

fixes problem introduced in https://github.com/Kong/kong/commit/5e25921de2da56eeb45042c5f7c74822584b7ddf

+5 -5

0 comment

2 changed files

Tieske

pr closed time in 6 days

Pull request review commentKong/kong

chore(oauth2) small cleanups on a merged pkce pr #5268

 describe("Plugin: oauth2 [#" .. strategy .. "]", function()         local body = assert.res_status(200, res)         assert.is_table(ngx.re.match(body, [[^\{"refresh_token":"[\w]{32,32}","token_type":"bearer","access_token":"[\w]{32,32}","expires_in":5\}$]]))       end)-      it("fails when code challenge contains + or / characters", function()+      it("success when code challenge contains + or / characters", function()
      it("succeeds when code challenge contains + or / characters", function()
bungle

comment created time in 7 days

PR opened Kong/kong-plugin-zipkin

feat(*) traceid bytes

This PR adds a new config option, traceid_bytes, which governs the length of the the automatically-generated traceids.

+97 -89

0 comment

4 changed files

pr created time in 8 days

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha e0b11da8e79c9580603986fbc3a8affbf8085ce7

tests(*) take wait_for_* helper functions out of main loop This is to facilitate reusing on other loops

view details

Enrique García Cota

commit sha b50e580b798d02f6f2d611fbf7d42bf1acee2b7a

feat(*) introduce new traceid_bytes property Allows configuring the length in bytes of the ids generated by the plugin

view details

push time in 8 days

create barnchKong/kong-plugin-zipkin

branch : feat/traceid-bytes

created branch time in 8 days

Pull request review commentKong/kong

refactor(plugins) use error(err) instead of kong.response.exit on 500 errors

 function RateLimitingHandler:access(conf)    local usage, stop, err = get_usage(conf, identifier, current_timestamp, limits)   if err then-    if fault_tolerant then-      kong.log.err("failed to get usage: ", tostring(err))-    else-      kong.log.err(err)-      return kong.response.exit(500, { message = "An unexpected error occurred" })+    if not fault_tolerant then

Why if not instead of if ?

bungle

comment created time in 14 days

Pull request review commentKong/kong

refactor(plugins) use error(err) instead of kong.response.exit on 500 errors

 function _M.execute(conf)   -- Load current metric for configured period   local usage, err = get_usage(conf, identifier, conf.limits, current_timestamp)   if err then-    if conf.fault_tolerant then-      kong.log.err("failed to get usage: ", tostring(err))-      return-    else-      return kong.response.exit(HTTP_INTERNAL_SERVER_ERROR, {-        message = "An unexpected error occurred"-      })+    if not conf.fault_tolerant then

Why was this if changed to a negative? In my opinion it is more difficult to read now.

bungle

comment created time in 14 days

push eventKong/kong

Thijs Schreijer

commit sha 1fe4b0beaca859c5bc37fd8e7be6460668087744

tests(helpers) fix the cn assertion (#5693) Had a bad description, fixed it and added a certificate modifier. Existing tests updated to use the new modifier

view details

push time in 14 days

delete branch Kong/kong

delete branch : cert-assert

delete time in 14 days

PR merged Kong/kong

tests(helpers) fix the cn assertion pr/please review

Had a bad description, fixed it and added a certificate modifier. Existing tests updated to use the new modifier

Related comment on previous PR: https://github.com/Kong/kong/pull/5643#discussion_r391672685

+140 -64

0 comment

4 changed files

Tieske

pr closed time in 14 days

push eventKong/kong

Thijs Schreijer

commit sha 718ffd63f13b17c662ff59364e4b2d3096367c62

chore(docs) add/update doc comments to/for the test helpers

view details

Thijs Schreijer

commit sha 71e9e000cc5f01991a881f405811e37abb8c3882

chore(docs) add setup for development doc generation

view details

push time in 15 days

delete branch Kong/kong

delete branch : dev-docs

delete time in 15 days

PR merged Kong/kong

Reviewers
Adds developer docs wrt test helpers pr/please review

The docs itself are not included, but the base files to generate are.

The updates to the helpers are only additional doc comments, and some reordering. No functional changes.

Results are not perfect, but seem complete.

+996 -291

0 comment

5 changed files

Tieske

pr closed time in 15 days

push eventKong/kong

Enrique García Cota

commit sha 86477b6abb94756371ac04ec0bb58d3f16bcc024

docs: admin api headers (#5662) * docs(admin-api) modify admin api header structure This change modifies the admin api generation in two ways: * Adds a new "indent" css class to certain elements. This should increase those element's left margin. * Replaces some "bold text sections" (markdown sections whose title was bold text instead of a header) by "real sections" (markdown sections with headers). The reason we used bold text was to prevent it from appearing on the automated nav tables, but that is not a problem any more (nav tables only look at levels >= 3). * docs(admin-api) skip deep branches when generating admin api nav This introduces a max_level (value = 3) beyond which links will not be generated. In other words all h4 and h5s will be skipped when generating the Admin API navigation. * docs(admin-api) reformat wide table This table was a little too wide for our docs website. I have slightly reworded things so that it properly fits. * docs(admin-api) split long code blocks in some generated tables The current version of the PR generates some very long field names, like `healthchecks.active.unhealthy.tcp_failures`, as well as some very long default values, like `[200, 201, 202, 203, 204, 205, 206, 207, 208, 226, 300, 301, 302, 303, 304, 305, 306, 307, 308]`. These very wide values are problematic when included inside tables, as code blocks (html does not know how to split them up, so they end up maximizing the tables, breaking layout and style). This change adds some "word breaks" (`<wbr>`) inside some of those long code blocks when they are inside tables, so that the browser knows it can break them at those points, fixing the table formatting issues.

view details

push time in 16 days

delete branch Kong/kong

delete branch : docs/admin-api-headers

delete time in 16 days

PR merged Kong/kong

docs: admin api headers

This change on the autodoc for the Admin API improves legibility on the Admin API headers and tables.

This has a sister PR in https://github.com/Kong/docs.konghq.com/pull/1851

+101 -56

1 comment

2 changed files

kikito

pr closed time in 16 days

push eventKong/kong

Enrique García Cota

commit sha 48839869373078171c8a186f1658a747a8c94b4a

chore(deps) bump kong-plugin-zipkin to 1.0.0

view details

push time in 16 days

pull request commentKong/kong

docs: admin api headers

Thanks for the approvals! I added a couple new changes in order to deal with wrongly formatted tables (unrelated with the other issues fixed on this PR), hopefully the docs people will be satisfied with those.

kikito

comment created time in 19 days

pull request commentKong/docs.konghq.com

fix(2.0.0) admin api headers

@GayleNeumann update on this one. I noticed some tables that were too wide. This is not a result of my current change, as they also present the same problem in the current version of the docs. I'm specifically talking about the tables around these links:

  • https://deploy-preview-1851--kongdocs.netlify.com/2.0.x/admin-api/#path-handling-algorithms
  • https://deploy-preview-1851--kongdocs.netlify.com/2.0.x/admin-api/#add-upstream

Nevertheless, I have included fixes for those tables as well. They should be visible soon.

kikito

comment created time in 19 days

push eventKong/docs.konghq.com

Enrique García Cota

commit sha 650439e393991d569337bebda9e4479139f11013

docs(2.0.0) regenerate admin API docs This regenerates the Admin API docs using the changes included in https://github.com/Kong/kong/pull/5662, which involve: * Replacing some "fake bold letters headers" with real headers * Adding the `indent` class to some of the generated headers and tables * Splitting long field names and default values with word breaks so that they don't break table layouts

view details

push time in 19 days

push eventKong/kong

Enrique García Cota

commit sha ae5679a0aa509206520301fb6bbe37811c3c0e59

docs(admin-api) reformat wide table This table was a little too wide for our docs website. I have slightly reworded things so that it properly fits.

view details

Enrique García Cota

commit sha 4a9aa7fc63af21866fa3d243ad9db7f86a2f8d03

docs(admin-api) split long code blocks in some generated tables The current version of the PR generates some very long field names, like `healthchecks.active.unhealthy.tcp_failures`, as well as some very long default values, like `[200, 201, 202, 203, 204, 205, 206, 207, 208, 226, 300, 301, 302, 303, 304, 305, 306, 307, 308]`. These very wide values are problematic when included inside tables, as code blocks (html does not know how to split them up, so they end up maximizing the tables, breaking layout and style). This change adds some "word breaks" (`<wbr>`) inside some of those long code blocks when they are inside tables, so that the browser knows it can break them at those points, fixing the table formatting issues.

view details

push time in 19 days

Pull request review commentKong/kong

Adds developer docs wrt test helpers

 local pack = function(...) return { n = select("#", ...), ... } end local unpack = function(t) return unpack(t, 1, t.n) end  --- Prints all returned parameters.--- Simple debugging aid.+-- Simple debugging aid, it will pass all received parameters, hence will not+-- influence the flow of the code. See also `fail`.

That section is already there in @see fail

-- influence the flow of the code.
Tieske

comment created time in 20 days

Pull request review commentKong/kong

Adds developer docs wrt test helpers

 Expected CN: Got instead: %s ]])+-- TODO: this seems broken, there seem to be no tests. A nicer assertion would be+-- assert.certificate.has.cn("somename.com")

If it's broken and no test is using it, I propose we remove it from the codebase instead.

Tieske

comment created time in 20 days

Pull request review commentKong/kong

Adds developer docs wrt test helpers

 local function admin_ssl_client(timeout)   return client end ++----------------+-- HTTP2 and GRPC clients+-- @section Shell-helpers+++-- Generate grpcurl flags from a table of `flag-value`. If `value` is not a+-- string, value is ignored and `flag` is passed as is.+local function gen_grpcurl_opts(opts_t)+  local opts_l = {}++  for opt, val in pairs(opts_t) do+    if val ~= false then+      opts_l[#opts_l + 1] = opt .. " " .. (type(val) == "string" and val or "")+    end+  end++  return table.concat(opts_l, " ")+end+++--- Creates an HTTP/2 client, based on the lua-http library.+-- @name http2_client+-- @param host hostname to connect to+-- @param port port to connect to+-- @param tls boolean indicating whether to establish a tls session+-- @return http2 client+local function http2_client(host, port, tls)+  local host = assert(host)+  local port = assert(port)+  tls = tls or false++  local request = require "http.request"+  local req = request.new_from_uri({+    scheme = tls and "https" or "http",+    host = host,+    port = port,+  })+  req.version = 2+  req.tls = tls++  if tls then+    local http_tls = require "http.tls"+    local openssl_ctx = require "openssl.ssl.context"+    local n_ctx = http_tls.new_client_context()+    n_ctx:setVerify(openssl_ctx.VERIFY_NONE)+    req.ctx = n_ctx+  end++  local meta = getmetatable(req) or {}++  meta.__call = function(req, opts)+    local headers = opts and opts.headers+    local timeout = opts and opts.timeout++    for k, v in pairs(headers or {}) do+      req.headers:upsert(k, v)+    end++    local headers, stream = req:go(timeout)+    local body = stream:get_body_as_string()+    return body, headers+  end++  return setmetatable(req, meta)+end+++--- returns a pre-configured cleartext `http2_client` for the Kong proxy port.+-- @name proxy_client_h2c+-- @return http2 client+local function proxy_client_h2c()+  local proxy_ip = get_proxy_ip(false, true)+  local proxy_port = get_proxy_port(false, true)+  assert(proxy_ip, "No http-proxy found in the configuration")+  return http2_client(proxy_ip, proxy_port)+end+++--- returns a pre-configured TLS `http2_client` for the Kong SSL proxy port.+-- @name proxy_client_h2+-- @return http2 client+local function proxy_client_h2()+  local proxy_ip = get_proxy_ip(true, true)+  local proxy_port = get_proxy_port(true, true)+  assert(proxy_ip, "No https-proxy found in the configuration")+  return http2_client(proxy_ip, proxy_port, true)+end++local exec -- forward declaration++--- Creates a gRPC client, based on the grpcurl CLI.+-- @name grpc_client+-- @param host hostname to connect to+-- @param port port to connect to+-- @param opts table with options supported by grpcurl+-- @return grpc client+local function grpc_client(host, port, opts)+  local host = assert(host)+  local port = assert(tostring(port))++  opts = opts or {}+  if not opts["-proto"] then+    opts["-proto"] = MOCK_GRPC_UPSTREAM_PROTO_PATH+  end++  return setmetatable({+    opts = opts,+    cmd_template = string.format("bin/grpcurl %%s %s:%s %%s", host, port)++  }, {+    __call = function(t, args)+      local service = assert(args.service)+      local body = args.body++      local t_body = type(body)+      if t_body ~= "nil" then+        if t_body == "table" then+          body = cjson.encode(body)+        end++        args.opts["-d"] = string.format("'%s'", body)+      end++      local opts = gen_grpcurl_opts(pl_tablex.merge(t.opts, args.opts, true))+      local ok, err, out = exec(string.format(t.cmd_template, opts, service))++      if ok then+        return ok, out+      else+        return nil, err+      end+    end+  })+end+++--- returns a pre-configured `grpc_client` for the Kong proxy port.+-- @name proxy_client_grpc+-- @param host hostname to connect to+-- @param port port to connect to+-- @return grpc client+local function proxy_client_grpc(host, port)+  local proxy_ip = host or get_proxy_ip(false, true)+  local proxy_port = port or get_proxy_port(false, true)+  assert(proxy_ip, "No http-proxy found in the configuration")+  return grpc_client(proxy_ip, proxy_port, {["-plaintext"] = true})+end++--- returns a pre-configured `grpc_client` for the Kong SSL proxy port.+-- @name proxy_client_grpcs+-- @param host hostname to connect to+-- @param port port to connect to+-- @return grpc client+local function proxy_client_grpcs(host, port)+  local proxy_ip = host or get_proxy_ip(true, true)+  local proxy_port = port or get_proxy_port(true, true)+  assert(proxy_ip, "No https-proxy found in the configuration")+  return grpc_client(proxy_ip, proxy_port, {["-insecure"] = true})+end++ --- -- TCP/UDP server helpers -- -- @section servers ---- Starts a TCP server.--- Accepts a single connection (or multiple, if given opts.requests)++--- Starts a local TCP server.+-- Accepts a single connection (or multiple, if given `opts.requests`) -- and then closes, echoing what was received (last read, in case -- of multiple requests).+--+-- Check the `kill_tcp_server` function for return values.

This seems in contradiction with the @return clause below it (the return values seem different in both functions). So maybe just remove this line?

Tieske

comment created time in 20 days

Pull request review commentKong/kong

Adds developer docs wrt test helpers

 end -- Modified version of `pl.utils.executeex()` so the output can directly be -- used on an assertion. -- @name execute--- @param cmd command to execute+-- @param cmd command string to execute -- @param pl_returns (optional) boolean: if true, this function will -- return the same values as Penlight's executeex.--- @return if pl_returns is true, returns four return values--- (ok, code, stdout, stderr); if pl_returns is false,+-- @return if `pl_returns` is true, returns four return values+-- (ok, code, stdout, stderr); if `pl_returns` is false, -- returns either (false, stderr) or (true, stderr, stdout).-local function exec(cmd, pl_returns)+function exec(cmd, pl_returns)

This seems to be creating a global variable called exec? Is it on purpose?

local function exec(cmd, pl_returns)
Tieske

comment created time in 20 days

Pull request review commentKong/kong

Adds developer docs wrt test helpers

 local function bootstrap_database(db)   end end +--- Gets the database utility helpers and prepares the database for a testrun.+-- This will a.o. bootstrap the datastore and truncate the existing data that+-- migth be in it. The BluePrint returned can be used to create test entities+-- in the database.+-- @name get_db_utils+-- @param strategy (optional) the database strategy to use, will default to the+-- strategy in the test configuration.+-- @param tables (optional) tables to truncate, this can be used to accelarate+-- tests if only a few tables are used. By default all tables will be truncated.+-- @param plugins (optional) array of plugins to load
-- @param plugins (optional) array of plugins to mark as loaded. Since kong will load all the bundled plugins by default, this is useful for mostly for marking custom plugins as loaded.
Tieske

comment created time in 20 days

PR opened Kong/kong

chore(deps) bump kong-plugin-zipkin to 1.0.0

<!-- NOTE: Please read the CONTRIBUTING.md guidelines before submitting your patch, and ensure you followed them all: https://github.com/Kong/kong/blob/master/CONTRIBUTING.md#contributing -->

Summary

SUMMARY_GOES_HERE

Full changelog

  • [Implement ...]
  • [Add related tests]
  • ...

Issues resolved

Fix #XXX

+6746 -4448

0 comment

89 changed files

pr created time in 20 days

create barnchKong/kong

branch : chore/bump-zipkin-100

created branch time in 20 days

pull request commentKong/docs.konghq.com

fix(2.0.0) admin api headers

Hi @GayleNeumann , could you tell me which tables seem broken to you? A link would be great, but just telling me their section would also work.

kikito

comment created time in 21 days

created tagKong/kong-plugin-zipkin

tagv1.0.0

A Kong plugin for propogating zipkin spans and reporting spans to a zipkin server

created time in 21 days

delete tag Kong/kong-plugin-zipkin

delete tag : 1.0.0

delete time in 21 days

created tagKong/kong-plugin-zipkin

tag1.0.0

A Kong plugin for propogating zipkin spans and reporting spans to a zipkin server

created time in 21 days

delete branch Kong/kong-plugin-zipkin

delete branch : release/1.0.0

delete time in 21 days

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha 8efd4d1f88b6189b68c7bff7a6a5680d4a8ebf4a

chore(*) release 1.0.0

view details

push time in 21 days

PR merged Kong/kong-plugin-zipkin

chore(*) release 1.0.0
+36 -17

2 comments

3 changed files

kikito

pr closed time in 21 days

PR opened Kong/docs.konghq.com

fix(2.0.0) admin api headers
+410 -280

0 comment

4 changed files

pr created time in 21 days

create barnchKong/docs.konghq.com

branch : fix/api-headers

created branch time in 21 days

PR opened Kong/kong

docs: admin api headers

This change on the autodoc for the Admin API improves legibility on the Admin API headers and tables.

+57 -44

0 comment

2 changed files

pr created time in 21 days

push eventKong/kong

Enrique García Cota

commit sha 37485063d371a5c2d93de49ef6feb0d46d1849e9

docs(admin-api) skip deep branches when generating admin api nav This introduces a max_level (value = 3) beyond which links will not be generated. In other words all h4 and h5s will be skipped when generating the Admin API navigation.

view details

push time in 21 days

create barnchKong/kong

branch : docs/admin-api-headers

created branch time in 21 days

Pull request review commentKong/kong-plugin-zipkin

Add support for W3C Trace Context

 if subsystem == "http" then     -- Want to send headers to upstream     local proxy_span = zipkin.proxy_span     local set_header = kong.service.request.set_header++    -- Set the W3C Trace Context header+    -- TODO: Should W3C traceparent header be set even it wasn't on the incoming request?

I asked myself a very similar question when implementing the b3 single header (#66).

In order to minimize the amount of configuration involved, I decided to take a salomonical approach: The plugin understands b3 single headers, but it only produces "regular" headers (such as x-b3-traceid).

It seemed an ok solution for the time but since we are adding a third kind of header I think we should control it via a new config file. A possible design would be:

options.header_types is a new config option with 3 possible values:

  • preserve: the plugin produces whatever format it receives on each request
  • b3-single: always use b3 single
  • b3: always use the "regular zipkin" headers, such as x-b3-traceid
  • w3c-trace-context: use the format proposed on this PR

When options.header_types is set to anything other than preserve, and the trace headers don't match (for example the config is b3-single but we receive a w3c-trace-context) then we should send both kinds of headers. We should also log a warning about the inconsistency.

If you want me to take over adding this, please let me know.

victorNewRelic

comment created time in 23 days

pull request commentKong/kong-plugin-zipkin

chore(*) release 1.0.0

We will not include #69 on this one just yet, please proceed with the regular review/approve process.

kikito

comment created time in 23 days

pull request commentKong/kong-plugin-zipkin

chore(*) release 1.0.0

Hold this while I review #69

kikito

comment created time in 23 days

Pull request review commentKong/docs.konghq.com

add grpc-web plugin to Kong Hub

+---+name: gRPC-Web+publisher: Kong Inc.++categories:+  - transformations++type: plugin++desc: Allow browser clients to call gRPC services.+description: |+  A Kong plugin to allow access to a gRPC service via the gRPC-Web protocol.+  Primarily, this means JS browser apps using the gRPC-Web library.+  +source_url: https://github.com/Kong/kong-plugin-grpc-web++license_type: MIT++kong_version_compatibility:+  community_edition:+    compatible:+      - 2.0.x+      - 1.5.x+      - 1.4.x+++params:+  name: grpc-web+  route_id: true+  protocols: ["http", "https"]+  dbless_compatible: true++  config:+    - name: proto+      required: false+      default:+      value_in_examples: path/to/hello.proto+      description: |+        If present, describes the gRPC types and methods.+        Required to support payload transcoding.  When absent, the+        web client must use application/grpw-web+proto content.++---++## Purpose++A service that presents a gRPC API can be used by clients written in many languages, but the network specifications are oriented primarily to connections within a datacenter.  In order to expose the API to the Internet, and to be called from brower-based JS apps, [gRPC-Web] was developed.++This plugin translates requests and responses between gRPC-Web and "real" gRPC.  Supports both HTTP/1.1 and HTTP/2, over plaintext (HTTP) and TLS (HTTPS) connections.++## Usage++This plugin is intended to be used in a Kong route between an HTTP endpoint and a gRPC service.

I agree that with "routes" it doesn't seem very useful. It makes more sense with more commonly-used names, like Services and Plugins. Kong can be a service in Kubernetes, and have many Services configured pointing to the other services.

javierguerragiraldez

comment created time in 23 days

PR opened Kong/kong-plugin-zipkin

chore(*) release 1.0.0
+36 -17

0 comment

3 changed files

pr created time in 23 days

create barnchKong/kong-plugin-zipkin

branch : release/1.0.0

created branch time in 23 days

CommitCommentEvent

delete branch Kong/kong-plugin-zipkin

delete branch : fix/timestamps

delete time in 23 days

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha 47bb8c47332432c7f36febf71ec956e505ec9fc1

fix(*) store annotation times in microseconds Zipkin expects all timestamps & durations to be in microseconds. However the annotation timestamps we were sending were in seconds. There were several sources of confusion here: * ngx native functions (like ngx.now) are in seconds * kong annotations (like ctx.KONG_ACCESS_START_TIME) are in *milliseconds* (not microseconds). * possibly as a leftover from the opentracing origins, the plugin tried to transform all the timestamps into *seconds* on span creation, and then tried to ransform them into microseconds just before sending them to zipkin * The span abstraction attempts to call ngx.now() when it is missing some timestamps, further blurring things up. A quick fix to the problem would have been transforming the annotations from seconds to microseconds right before sending them to zipkin, just like it was being done with start_time and duration. But this approach would have required 3 extra table allocations per request. It would also remain a bit obscure because of the transformation to seconds first, and then into microseconds. Instead, the changes have been as follows: * The span abstraction is not able to "fill up" the timestamp and call ngx.now or something else. It expects all timestamps to be filled up, or it explodes (all of our timestamps were actually already filled in so this was dead code). * The span abstraction expects all times to be specified in *microseconds* already. To stress this out, all timestamps params have been renamed to _mu (for example start_timestamp becomes start_timestamp_mu). It also invokes math.floor on all timestamps because zipkin demmands integers. * The code in the handler is in charge of making the transformation into microseconds directly. * The reporter does not do any transformations on the timestamps

view details

Enrique García Cota

commit sha a19c4e633e5a31735836962141689194c1219ae0

fix(handler) don't assume ctx.KONG_* vars are set Fixes #68 The plugin assumed that certain variables such as `ctx.KONG_ACCESS_START` were always set. There are occasions where this isn't true, for example an auth plugin might skip the access phase altogether. The assumption provoked unwanted status reports. In #68 we can see an example in which the expected status code is 400 but because of this assumption we get 500 instead. This wraps all accesses to ctx.KONG_* with conditionals, using other values such as ngx_now_mu() if they are not present. There is some repetitiveness, but I resisted abstracting into a function to allow for short-circuiting the call to obtain the default value (i.e. to only call to ngx_now() when it was really needed).

view details

push time in 23 days

PR merged Kong/kong-plugin-zipkin

fix(*) timestamps

This PR contains two different fixes related with handling of timestamps on this plugin.

Fixes #68 .

+120 -88

0 comment

4 changed files

kikito

pr closed time in 23 days

issue closedKong/kong-plugin-zipkin

Assumption KONG_ACCESS_START will always be set in tx context.

Hit a tx that was blocked by the Mod Security NGINX WAF returning a 400 to the client. The Log phase Zipkin execution assumed that KONG_ACCESS_START would be set in such a case when it must not get set in these cases. Other NGINX modules may do so as well due to short circuit. I supposed when Kong short circuits via access blocking etc auth plugins/acl plugins. the KONG_ACCESS_START is set.

2020/02/13 09:19:20 [error] 72#0: *37331 failed to run log_by_lua*: ...arocks/share/lua/5.1/kong/plugins/zipkin/opentracing.lua:208: attempt to perform arithmetic on field 'KONG_ACCESS_START' (a nil value)
--
  | stack traceback:
  | ...arocks/share/lua/5.1/kong/plugins/zipkin/opentracing.lua:208: in function 'log'
  | ...g/luarocks/share/lua/5.1/kong/plugins/zipkin/handler.lua:34: in function <...g/luarocks/share/lua/5.1/kong/plugins/zipkin/handler.lua:33>
  | /usr/local/kong/luarocks/share/lua/5.1/kong/init.lua:209: in function 'execute_plugins_iterator'
  | /usr/local/kong/luarocks/share/lua/5.1/kong/init.lua:1068: in function 'log'
  | log_by_lua(nginx.conf:167):2: in main chunk while logging request, client: 10.96.29.29, server: kong, request: "GET /api/pdr/demo/test/v1.0?appealid=13414&trackingid=518sourcesystem=ETS HTTP/1.1", host: "gateway.company.com"

Might be worth considering the case that it's not set though to prevent NPE's. Generally preventing nil pointers in app execution is good anyways with proper checking in place due to 3rd party modules and integrations.

closed time in 23 days

jeremyjpj0916

Pull request review commentKong/kong

feat(proxy/pdk) add support for X-Forwarded-Prefix

 return {        local trusted_ip = kong.ip.is_trusted(realip_remote_addr)       if trusted_ip then-        forwarded_proto = var.http_x_forwarded_proto or scheme-        forwarded_host  = var.http_x_forwarded_host  or host-        forwarded_port  = var.http_x_forwarded_port  or port+        forwarded_proto  = var.http_x_forwarded_proto  or scheme+        forwarded_host   = var.http_x_forwarded_host   or host+        forwarded_port   = var.http_x_forwarded_port   or port+        forwarded_prefix = var.http_x_forwarded_prefix        else-        forwarded_proto = scheme-        forwarded_host  = host-        forwarded_port  = port+        forwarded_proto  = scheme+        forwarded_host   = host+        forwarded_port   = port+      end++      if not forwarded_prefix then+        forwarded_prefix = var.request_uri+        local p = find(forwarded_prefix, "?", 2, true)

This removal of the query seems to be done here but not on the pdk function. Shouldn't they behave the same way?

bungle

comment created time in a month

Pull request review commentKong/kong

feat(proxy/pdk) add support for X-Forwarded-Prefix

 local function new(self)   end  +  ---+  -- Returns the path component of the request's URL, but also considers+  -- `X-Forwarded-Prefix` if it comes from a trusted source. The value+  -- is returned as a Lua string.+  --+  -- Whether this function considers `X-Forwarded-Prefix` or not depends on+  -- several Kong configuration parameters:+  --+  -- * [trusted\_ips](https://getkong.org/docs/latest/configuration/#trusted_ips)+  -- * [real\_ip\_header](https://getkong.org/docs/latest/configuration/#real_ip_header)+  -- * [real\_ip\_recursive](https://getkong.org/docs/latest/configuration/#real_ip_recursive)+  --+  -- **Note**: we do not currently do any normalization on the request+  --           path except return `"/"` on empty path.

This seems false or incomplete, there is some normalization going on on the last line of this function.

bungle

comment created time in a month

Pull request review commentKong/kong

feat(oauth2) optionally hash client secret

+local utils = require "kong.tools.utils"+++local type = type+local find = string.find+local pcall = pcall+local remove = table.remove+local concat = table.concat+local assert = assert+++--local CORES+--do+--  local infos = utils.get_system_infos()+--  if type(infos) == "table" then+--    CORES = infos.cores+--  end+--  if not CORES then+--    CORES = ngx.worker.count() or 1+--  end+--end+++local PREFIX = nil -- currently chosen algorithm+++local ARGON2+local ARGON2_ID = "$argon2"+do+  local ARGON2_PREFIX+  local ok, crypt = pcall(function()+    local argon2 = require "argon2"++    -- argon2 settings+    local ARGON2_VARIANT     = argon2.variants.argon2_id+    local ARGON2_PARALLELISM = 1 --CORES+    local ARGON2_T_COST      = 1+    local ARGON2_M_COST      = 4096+    local ARGON2_HASH_LEN    = 32+    local ARGON2_SALT_LEN    = 16++    local ARGON2_OPTIONS = {+      variant     = ARGON2_VARIANT,+      parallelism = ARGON2_PARALLELISM,+      hash_len    = ARGON2_HASH_LEN,+      t_cost      = ARGON2_T_COST,+      m_cost      = ARGON2_M_COST,+    }+    do+      local hash = argon2.hash_encoded("", utils.get_rand_bytes(ARGON2_SALT_LEN), ARGON2_OPTIONS)+      local parts = utils.split(hash, "$")+      remove(parts)+      remove(parts)+      ARGON2_PREFIX = concat(parts, "$")+    end++    local secret = {}++    function secret.hash(secret)+      return argon2.hash_encoded(secret, utils.get_rand_bytes(ARGON2_SALT_LEN), ARGON2_OPTIONS)+    end++    function secret.verify(secret, hash)+      return argon2.verify(hash, secret)+    end++    return secret+  end)++  if ok then+    ARGON2 = crypt+    PREFIX = PREFIX or ARGON2_PREFIX+  end+end+++local BCRYPT+local BCRYPT_ID = "$2"+do+  local BCRYPT_PREFIX+  local ok, crypt = pcall(function()

Same as before: wrap only the require with pcall.

bungle

comment created time in a month

Pull request review commentKong/kong

feat(oauth2) optionally hash client secret

+local utils = require "kong.tools.utils"+++local type = type+local find = string.find+local pcall = pcall+local remove = table.remove+local concat = table.concat+local assert = assert+++--local CORES+--do+--  local infos = utils.get_system_infos()+--  if type(infos) == "table" then+--    CORES = infos.cores+--  end+--  if not CORES then+--    CORES = ngx.worker.count() or 1+--  end+--end+++local PREFIX = nil -- currently chosen algorithm+++local ARGON2+local ARGON2_ID = "$argon2"+do+  local ARGON2_PREFIX+  local ok, crypt = pcall(function()

I suggest not wrapping the whole declaration with pcall. Consider what will happen if someone modifies this code in the future and introduces a typo which makes this function always fail. Then the app will always pick bcrypt. If the pcall is supposed to detect that require "argon2" throws, then wrap only that with pcall.

bungle

comment created time in a month

Pull request review commentKong/kong

feat(oauth2) optionally hash client secret

+return {+  postgres = {+    up = [[+      DO $$+      BEGIN+        ALTER TABLE IF EXISTS ONLY oauth2_credentials ADD hash_secret BOOLEAN DEFAULT FALSE;

I believe adding the default on fields on the migrations like this is not the recommended way, because then it can conflict with the schema default in the future.

        ALTER TABLE IF EXISTS ONLY oauth2_credentials ADD hash_secret BOOLEAN;
bungle

comment created time in a month

Pull request review commentKong/kong

feat(oauth2) optionally hash client secret

+local utils = require "kong.tools.utils"+++local type = type+local find = string.find+local pcall = pcall+local remove = table.remove+local concat = table.concat+local assert = assert+++--local CORES+--do+--  local infos = utils.get_system_infos()+--  if type(infos) == "table" then+--    CORES = infos.cores+--  end+--  if not CORES then+--    CORES = ngx.worker.count() or 1+--  end+--end

Is this a vestige from development?

bungle

comment created time in a month

Pull request review commentKong/kong

feat(pdk) error method honoring Accept header

 describe("Utils", function()       end, "scale must be equal or greater than 0")     end)   end)++  describe("get_mime_type()", function()+    it("with valid mime types", function()+      assert.equal("application/json; charset=utf-8", utils.get_mime_type("application/json"))+      assert.equal("application/json; charset=utf-8", utils.get_mime_type("application/json; charset=utf-8"))+      assert.equal("application/json; charset=utf-8", utils.get_mime_type("application/*"))+      assert.equal("application/json; charset=utf-8", utils.get_mime_type("application/*; charset=utf-8"))+      assert.equal("text/html; charset=utf-8", utils.get_mime_type("text/html"))+      assert.equal("text/plain; charset=utf-8", utils.get_mime_type("text/plain"))+      assert.equal("text/plain; charset=utf-8", utils.get_mime_type("text/*"))+      assert.equal("text/plain; charset=utf-8", utils.get_mime_type("text/*; charset=utf-8"))+      assert.equal("application/xml; charset=utf-8", utils.get_mime_type("application/xml"))+      assert.equal("", utils.get_mime_type("application/grpc"))+    end)++    it("with unsupported or invalid mime types", function()+      assert.equal("application/json; charset=utf-8", utils.get_mime_type("audio/*", true))+      assert.equal("application/json; charset=utf-8", utils.get_mime_type("text/css"))

Please add a line for the "default" content type, which is a bit special since it is defined as CONTENT_TYPE_DEFAULT:

      assert.equal("application/json; charset=utf-8", utils.get_mime_type("text/css"))
      assert.equal("application/json; charset=utf-8", utils.get_mime_type("default"))
locao

comment created time in a month

Pull request review commentKong/kong

feat(pdk) error method honoring Accept header

 for _, strategy in helpers.each_strategy() do         })         assert.res_status(401, res)         local body = assert.res_status(401, res)-        assert.equal([[{"message":"No API key found in request"}]], body)+        assert.equal("{\n  \"message\":\"No API key found in request\"\n}", body)

Let's not tie ourselves to those blank characters:

        assert.same({message = "No API key found in request"}, cjson.parse(body))
locao

comment created time in a month

Pull request review commentKong/docs.konghq.com

add grpc-web plugin to Kong Hub

+---+name: gRPC-Web+publisher: Kong Inc.++categories:+  - transformations++type: plugin++desc: Allow browser clients to call gRPC services.+description: |+  A Kong plugin to allow access to a gRPC service via the gRPC-Web protocol.+  Primarily, this means JS browser apps using the gRPC-Web library.+  +source_url: https://github.com/Kong/kong-plugin-grpc-web++license_type: MIT++kong_version_compatibility:+  community_edition:+    compatible:+      - 2.0.x+      - 1.5.x+      - 1.4.x+++params:+  name: grpc-web+  route_id: true+  protocols: ["http", "https"]+  dbless_compatible: true++  config:+    - name: proto+      required: false+      default:+      value_in_examples: path/to/hello.proto+      description: |+        If present, describes the gRPC types and methods.+        Required to support payload transcoding.  When absent, the+        web client must use application/grpw-web+proto content.++---++## Purpose++A service that presents a gRPC API can be used by clients written in many languages, but the network specifications are oriented primarily to connections within a datacenter.  In order to expose the API to the Internet, and to be called from brower-based JS apps, [gRPC-Web] was developed.++This plugin translates requests and responses between gRPC-Web and "real" gRPC.  Supports both HTTP/1.1 and HTTP/2, over plaintext (HTTP) and TLS (HTTPS) connections.++## Usage++This plugin is intended to be used in a Kong route between an HTTP endpoint and a gRPC service.++Sample configuration via declarative (YAML):++```yaml+_format_version: "1.1"+services:+- protocol: grpc+  host: localhost+  port: 9000+  routes:+  - protocols:+    - http+    paths:+    - /+    plugins:+    - name: grpc-web+```++Same thing via the Admin API:++```bash+$ # add the gRPC service+$ curl -XPOST localhost:8001/services \+  --data name=grpc \+  --data protocol=grpc \+  --data host=localhost \+  --data port=9000++$ # add an http route+$ curl -XPOST localhost:8001/services/grpc/routes \+  --data protocols=http \+  --data name=web-service \+  --data paths=/++$ # add the plugin to the route+$ curl -XPOST localhost:8001/routes/web-service/plugins \+  --data name=grpc-web+```++In these examples we don't set any configuration for the plugin.  This minimal setup works for the default varieties of the [gRPC-Web protocol], which use ProtocolBuffer messages either directly in binary or with base64 encoding.  The related `Content-Type` headers are `application/grpc-web` or `application/grpc-web+proto` for binary and `application/grpc-web-text` or `application/grpc-web-text+proto`.++If we wish to use JSON encoding, we have to provide the gRPC specification in a .proto file, which needs to be installed in the Kong node running the plugin.  For example:++```protobuf+syntax = "proto2";++package hello;++service HelloService {+  rpc SayHello(HelloRequest) returns (HelloResponse);+  rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);+  rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);+  rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);+}++message HelloRequest {+  optional string greeting = 1;+}++message HelloResponse {+  required string reply = 1;+}+```++The declarative configuration becomes:++```yaml+_format_version: "1.1"+services:+- protocol: grpc+  host: localhost+  port: 9000+  routes:+  - protocols:+    - http+    paths:+    - /+    plugins:+    - name: grpc-web+      proto: path/to/hello.proto+```++or via the Admin API:++```bash+$ # add the plugin to the route+$ curl -XPOST localhost:8001/routes/web-service/plugins \+  --data name=grpc-web \+  --data proto=path/to/hello.proto+```++With this setup, we can support gRPC-Web/JSON clients using `Content-Type` headers like `application/grpc-web+json` or `application/grpc-web-text+json`.++Additionaly, non-gRPC-Web clients can do simple POST requests with `Content-Type: application/json`.  In this case, the data payloads are simple JSON objects, without gPRC frames.  This allows clients to perform calls without using the gRPC-Web library, but streaming responses are delivered as a continous stream of JSON objects.  It's up to the client to split into separate objects if it has to support multiple response messages.

I don't understand what this paragraph means. When a user does a POST with Content-Type: application/json, what happens?

the data payloads are simple JSON objects, without gPRC frames

What does "data payloads" mean here? Is it the consumer -> kong request, the kong -> upstream request, the upstream -> kong response, the kong -> user response, or all of them? My best understanding of this (with low trust) is "the JSON request is proxied verbatim to the upstream". Why? Is it just that the plugin isn't activated by this calls (so they are proxied transparently)?

streaming responses are delivered as a continous stream of JSON objects

Does this mean that if I send a (non-html) TCP request the plugin is not activated and the TCP input will be proxied to the upstream without any transformation? Or I am not understanding something?

javierguerragiraldez

comment created time in a month

Pull request review commentKong/docs.konghq.com

add grpc-web plugin to Kong Hub

+---+name: gRPC-Web+publisher: Kong Inc.++categories:+  - transformations++type: plugin++desc: Allow browser clients to call gRPC services.+description: |+  A Kong plugin to allow access to a gRPC service via the gRPC-Web protocol.+  Primarily, this means JS browser apps using the gRPC-Web library.+  +source_url: https://github.com/Kong/kong-plugin-grpc-web++license_type: MIT++kong_version_compatibility:+  community_edition:+    compatible:+      - 2.0.x+      - 1.5.x+      - 1.4.x+++params:+  name: grpc-web+  route_id: true+  protocols: ["http", "https"]+  dbless_compatible: true++  config:+    - name: proto+      required: false+      default:+      value_in_examples: path/to/hello.proto+      description: |+        If present, describes the gRPC types and methods.+        Required to support payload transcoding.  When absent, the+        web client must use application/grpw-web+proto content.++---++## Purpose++A service that presents a gRPC API can be used by clients written in many languages, but the network specifications are oriented primarily to connections within a datacenter.  In order to expose the API to the Internet, and to be called from brower-based JS apps, [gRPC-Web] was developed.++This plugin translates requests and responses between gRPC-Web and "real" gRPC.  Supports both HTTP/1.1 and HTTP/2, over plaintext (HTTP) and TLS (HTTPS) connections.++## Usage++This plugin is intended to be used in a Kong route between an HTTP endpoint and a gRPC service.
This plugin is intended to be used in a Kong Route between an HTTP endpoint and a gRPC service.
javierguerragiraldez

comment created time in a month

Pull request review commentKong/docs.konghq.com

add grpc-web plugin to Kong Hub

+---+name: gRPC-Web+publisher: Kong Inc.++categories:+  - transformations++type: plugin++desc: Allow browser clients to call gRPC services.+description: |+  A Kong plugin to allow access to a gRPC service via the gRPC-Web protocol.+  Primarily, this means JS browser apps using the gRPC-Web library.+  +source_url: https://github.com/Kong/kong-plugin-grpc-web++license_type: MIT++kong_version_compatibility:+  community_edition:+    compatible:+      - 2.0.x+      - 1.5.x+      - 1.4.x+++params:+  name: grpc-web+  route_id: true+  protocols: ["http", "https"]+  dbless_compatible: true++  config:+    - name: proto+      required: false+      default:+      value_in_examples: path/to/hello.proto+      description: |+        If present, describes the gRPC types and methods.+        Required to support payload transcoding.  When absent, the+        web client must use application/grpw-web+proto content.++---++## Purpose++A service that presents a gRPC API can be used by clients written in many languages, but the network specifications are oriented primarily to connections within a datacenter.  In order to expose the API to the Internet, and to be called from brower-based JS apps, [gRPC-Web] was developed.++This plugin translates requests and responses between gRPC-Web and "real" gRPC.  Supports both HTTP/1.1 and HTTP/2, over plaintext (HTTP) and TLS (HTTPS) connections.

Adding links to protocols.

This plugin translates requests and responses between [gRPC-Web](https://github.com/grpc/grpc-web) and ["real" gRPC](https://github.com/grpc/grpc).  Supports both HTTP/1.1 and HTTP/2, over plaintext (HTTP) and TLS (HTTPS) connections.
javierguerragiraldez

comment created time in a month

Pull request review commentKong/docs.konghq.com

add grpc-web plugin to Kong Hub

+---+name: gRPC-Web+publisher: Kong Inc.++categories:+  - transformations++type: plugin++desc: Allow browser clients to call gRPC services.+description: |+  A Kong plugin to allow access to a gRPC service via the gRPC-Web protocol.+  Primarily, this means JS browser apps using the gRPC-Web library.+  +source_url: https://github.com/Kong/kong-plugin-grpc-web++license_type: MIT++kong_version_compatibility:+  community_edition:+    compatible:+      - 2.0.x+      - 1.5.x+      - 1.4.x+++params:+  name: grpc-web+  route_id: true+  protocols: ["http", "https"]+  dbless_compatible: true++  config:+    - name: proto+      required: false+      default:+      value_in_examples: path/to/hello.proto+      description: |+        If present, describes the gRPC types and methods.+        Required to support payload transcoding.  When absent, the+        web client must use application/grpw-web+proto content.++---++## Purpose++A service that presents a gRPC API can be used by clients written in many languages, but the network specifications are oriented primarily to connections within a datacenter.  In order to expose the API to the Internet, and to be called from brower-based JS apps, [gRPC-Web] was developed.

That last phrase is a bit Yoda.

A service that presents a gRPC API can be used by clients written in many languages, but the network specifications are oriented primarily to connections within a datacenter. [gRPC-Web] allows exposing such API to the Internet, and be consumed by brower-based JS apps. 
javierguerragiraldez

comment created time in a month

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha af6164223ec6071ceabbbbf0f868d579e7af24d0

fix(handler) send TCP traffic correctly (#70) This commit fixes a problem when tracing TCP traffic, and adds an integration test which exercises that branch.

view details

Enrique García Cota

commit sha 8e4e78a672f4a1f9d8f28794729ced06a77dc323

fix(*) store annotation times in microseconds Zipkin expects all timestamps & durations to be in microseconds. However the annotation timestamps we were sending were in seconds. There were several sources of confusion here: * ngx native functions (like ngx.now) are in seconds * kong annotations (like ctx.KONG_ACCESS_START_TIME) are in *milliseconds* (not microseconds). * possibly as a leftover from the opentracing origins, the plugin tried to transform all the timestamps into *seconds* on span creation, and then tried to ransform them into microseconds just before sending them to zipkin * The span abstraction attempts to call ngx.now() when it is missing some timestamps, further blurring things up. A quick fix to the problem would have been transforming the annotations from seconds to microseconds right before sending them to zipkin, just like it was being done with start_time and duration. But this approach would have required 3 extra table allocations per request. It would also remain a bit obscure because of the transformation to seconds first, and then into microseconds. Instead, the changes have been as follows: * The span abstraction is not able to "fill up" the timestamp and call ngx.now or something else. It expects all timestamps to be filled up, or it explodes (all of our timestamps were actually already filled in so this was dead code). * The span abstraction expects all times to be specified in *microseconds* already. To stress this out, all timestamps params have been renamed to _mu (for example start_timestamp becomes start_timestamp_mu). It also invokes math.floor on all timestamps because zipkin demmands integers. * The code in the handler is in charge of making the transformation into microseconds directly. * The reporter does not do any transformations on the timestamps

view details

Enrique García Cota

commit sha e63b65052e2b68fa3660212d0436897312e7d192

fix(handler) don't assume ctx.KONG_* vars are set Fixes #68 The plugin assumed that certain variables such as `ctx.KONG_ACCESS_START` were always set. There are occasions where this isn't true, for example an auth plugin might skip the access phase altogether. The assumption provoked unwanted status reports. In #68 we can see an example in which the expected status code is 400 but because of this assumption we get 500 instead. This wraps all accesses to ctx.KONG_* with conditionals, using other values such as ngx_now_mu() if they are not present. There is some repetitiveness, but I resisted abstracting into a function to allow for short-circuiting the call to obtain the default value (i.e. to only call to ngx_now() when it was really needed).

view details

push time in a month

PR opened Kong/kong-plugin-zipkin

fix(*) timestamps

This PR contains two different fixes related with handling of timestamps on this plugin.

Fixes #68 .

Depends on #70. This will remain a draft PR until that other PR is merged.

+253 -90

0 comment

4 changed files

pr created time in a month

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha ad0f4b6b73face5ad6b0cbf88cc3e2e9ffb4e6cb

fix(handler) don't assume ctx.KONG_* vars are set Fixes #68 The plugin assumed that certain variables such as `ctx.KONG_ACCESS_START` were always set. There are occasions where this isn't true, for example an auth plugin might skip the access phase altogether. The assumption provoked unwanted status reports. In #68 we can see an example in which the expected status code is 400 but because of this assumption we get 500 instead. This wraps all accesses to ctx.KONG_* with conditionals, using other values such as ngx_now_mu() if they are not present. There is some repetitiveness, but I resisted abstracting into a function to allow for short-circuiting the call to obtain the default value (i.e. to only call to ngx_now() when it was really needed).

view details

push time in a month

create barnchKong/kong-plugin-zipkin

branch : fix/timestamps

created branch time in a month

PR opened Kong/kong-plugin-zipkin

fix(handler) send TCP traffic correctly

This commit fixes a problem when tracing TCP traffic, and adds an integration test which exercises that branch.

+137 -6

0 comment

2 changed files

pr created time in a month

push eventKong/kong-plugin-zipkin

Enrique García Cota

commit sha 333e8509694440bdf75ee1654dd42b426fb88df2

fix(handler) send TCP traffic correctly This commit fixes a problem when tracing TCP traffic, and adds an integration test which exercises that branch.

view details

push time in a month

create barnchKong/kong-plugin-zipkin

branch : fix/tcp

created branch time in a month

Pull request review commentKong/kong

chore(ci) make sure tags dont get built by the nightly cron

 pipeline {     agent none+    triggers {+        cron(env.BRANCH_NAME == 'master' | env.BRANCH_NAME == 'next' ? '@daily' : '')+    }+    options {+        retry(1)+        parallelsAlwaysFailFast()+        timeout(time: 2, unit: 'HOURS')+    }     environment {         UPDATE_CACHE = "true"         DOCKER_CREDENTIALS = credentials('dockerhub')         DOCKER_USERNAME = "${env.DOCKER_CREDENTIALS_USR}"         DOCKER_PASSWORD = "${env.DOCKER_CREDENTIALS_PSW}"         KONG_PACKAGE_NAME = "kong"     }-    triggers {-        cron('@daily')-    }     stages {         stage('Build Kong') {+            when {+                beforeAgent true+                anyOf {+                    allOf {+                        buildingTag()+                        not { triggeredBy 'TimerTrigger' }+                    }+                    allOf {+                        triggeredBy 'TimerTrigger'+                        anyOf { branch 'master'; branch 'next' }+                    }+                }+            }

Please put that in a comment on the file, too.

hutchic

comment created time in a month

delete branch Kong/homebrew-kong

delete branch : fix/kong-upgrade-tools

delete time in a month

push eventKong/homebrew-kong

Enrique García Cota

commit sha 01d200841c97a4d457b1769bd37f1ab63724a9d2

fix(openresty) use kong-upgrade-tools to get the latest openrest… (#133) In order to get the latest openresty patches

view details

push time in a month

PR merged Kong/homebrew-kong

fix(openresty) use kong-upgrade-tools to get the latest openresty patches

This is done in order to get the latest openresty patches.

+17 -8

0 comment

1 changed file

kikito

pr closed time in a month

Pull request review commentKong/kong

ci(github) use GitHub Actions as CI for Kong OSS

 else fi  if [ "$TEST_SUITE" == "integration" ]; then-    eval "$TEST_CMD" spec/02-integration/+    if [ "$TEST_SPLIT" == "first" ]; then+        # GitHub Actions, run first half of integration tests+        eval "$TEST_CMD" $(ls -d spec/02-integration/* | head -n4)++    elif [ "$TEST_SPLIT" == "second" ]; then+        # GitHub Actions, run second half of integration tests+        # In case of odd number of directories, the second half will be+        # running one more directory than the first+        eval "$TEST_CMD" $(ls -d spec/02-integration/* | tail -n+5)

The biggest drawback about this is that in in order to to know whether an individual test goes into "first" and or "second" is to look at this file. I think this could be improved by an explicit renaming: integration first half could be renamed to 02-integration/01-04 and integration second half to 02-integration/05-xx.

I see some alternatives, but they also have problems.

We could make the split directly on the filesystem (splitting spec/02-integration/* into two folders).

  • Pro: To know what half your file is in, just look at the path. It is very "obvious".
  • Pro: Impossible to forget to "assign a half" to a test.
  • Con: Need "manually move files and folders from one folder to the other" from time to time in order to keep both halves "balanced".
  • Con: Ties the "logical layout" of the tests to a "physical need" of one particular CI server.

We could add tags to the top describe on each file and use that for filtering.

  • Pro: To know what "half" your file is in, just look at the top describe.
  • Pro: "moving files from one half to the other" is a small diff - just retag.
  • Pro: Allows for more granular splitting (by file instead of by folder). We could potentially split further (by test) but I don't think that's needed.
  • Con: First commit would require manually tagging all files.
  • Con: Need to remember to add the tag on files to keep things balanced.
  • Con: Potentially execute before blocks that we don't need.
  • Con: The "names" of each group of test would have to remain "nebulous", like "first" and "second", or "red" and "blue".

If I had done this PR, I would have probably gone with the tags, since they look like a more natural fit to me. However the current approach has its own merits (provided we rename to something more obvious).

dndx

comment created time in a month

issue commentKong/kong

bug: upstream host_header is not respected when preserving host

Hey, @locao , you added host_header in #4959. Do you have an opinion on this one?

hbagdi

comment created time in a month

more