Kong 1.4.0rc2 available for testing!

Hello Kong Nation!

We are happy to announce the availability of the second release candidate, Kong 1.4.0rc2 that has just gone out and is ready for testing!

Kong 1.4 adds the Cassandra cluster topology refresh feature, the new status interface, the transformations DAO property, and the ability to change the hostname used to connect to proxied servers.

:package: Download Kong 1.4.0rc2 today — as always we are looking forward to your feedback!

For updated information on upgrading to 1.4.0rc2, please check the docs: https://github.com/Kong/kong/blob/1.4.0rc2/UPGRADE.md. The official install docs can be found at: https://konghq.com/install.

What’s new in Kong 1.4.0rc2 :fireworks:

  • :lock: Security
    • Service Mesh is being discontinued in the next major release of Kong, as it is known to cause HTTPS requests to upstream to ignore proxy_ssl* directives. In this release it is disabled by default, avoiding this issue, and it can be enabled in the configuration section.
  • :construction_worker_woman: Core
    • Fixed an issue on reporting the proper request method and URL arguments on NGINX-produced errors in logging plugins. #5073
    • Fixed possible deadlocks cases in database access functions when using Postgres and cleaning up cluster_events in high-changing scenarios. #5118
  • :file_folder: Configuration
    • Automatically escape any unescaped # characters in parsed KONG_* environment variables.
  • :electric_plug: Plugins
    • jwt: plugin handles empty claims and return the correct error message. #5123
    • serverless-functions: Lua code in declarative configurations is validated and loaded correctly. #24
    • request-transformer: fixed bug on removing and then adding request headers with the same name #9

And a recap of all the new stuff in the 1.4 series :fireworks:

  • :fireworks: New configuration option cassandra_refresh_frequency to set the frequency that Kong will check for Cassandra cluster topology changes, avoiding restarts when Cassandra nodes are added or removed. #5071
  • :fireworks: New transformations property in DAO schemas, which allows adding functions that run when database rows are inserted or updated. ssandra cluster topology changes, avoiding restarts when Cassandra nodes are added or removed. #5047
  • :fireworks: The new attribute hostname has been added to upstreams entities. This attribute is used as the Host header when proxying requests through Kong to servers that are listening on server names that are different from the names to which they resolve. #4959
  • :fireworks: The new status interface has been introduced. It exposes insensitive health, metrics and error read-only information from Kong, which can be consumed by other services in the infrastructure to monitor Kong’s health. This removes the requirement of the long-used workaround to monitor Kong’s health by injecting a custom server block. #4977
  • :fireworks: New configuration option router_update_frequency that allows setting the frequency that router and plugins will be checked for changes. This new option avoids performance degradation when Kong routes or plugins are frequently changed. #4897
  • New Admin API response header X-Kong-Admin-Latency, reporting the time taken by Kong to process an Admin API request. #4966
  • In addition to consumer, credential, and IP levels, now rate-limiting plugin has service-level support. #5031
  • Now rate-limiting local policy counters expire using the shared dictionary’s TTL, avoiding to keep unnecessary counters in memory. #5029
  • Authentication plugins have support for tags now. #4945
  • The response-transformer plugin now supports renaming response headers. #5040

:spiral_notepad: Here’s a link to the 1.4.0rc2 Changelog .

We encourage everyone to run this release candidate in their test environments and give us your feedback! This forum is a great way to ask questions or post feedback, and the GitHub issues is the place for bug reports.

Thank you all for the feedback in this release candidate series, and keep it coming! :revolving_hearts:

1 Like

Just thinking in practice it would help to script the release candidates / main releases to go in all the various destinations uniformly:

For instance:


Has Kong 1.3.0rc2-0 present but not the 1.4.0rc2 candidate (which seems to have been dropped on bintray only) . I also see docker hub:
https://hub.docker.com/_/kong has Kong 1.4.0rc1 but not rc2 yet.

I currently build from src out of necessity and use the luarocks packages for builds much like the Kong build script repos. So would have to adjust my dev environment to use bintray at the moment.

So maybe something that throws it up on:
Docker Hub

For every release candidate / release would be helpful to get the most engagement from community testers and their various deploy patterns.


Hi Jeremy,

Thanks for your suggestions (and for your contributions for the 1.4 :slight_smile: )!

We deliver the release candidates on the Docker Hub, but we have no control on how long it will take to be available, as the guys there have too much to take care. The PR is open, and it should be available soon.

But we should not deliver the release candidates for the Luarocks repository, as they are experimental versions and we prefer that repository to have only the stable ones. The 1.3.0rc2 package shouldn’t be there, thanks for noticing that. We can think on some way to deliver there in the future, but that’s the policy for now.


1 Like

Hi Jeremy,

The official 1.4.0rc2 Docker image is already available.


1 Like