Releases: fanduel-oss/jsonrpc2-elixir
v2.0.0
Important v2.0 Change
tl;dr
The TCP/TLS server/client default packet format has changed in v2.0, causing backwards incompatibility.
If your existing servers/clients are working fine in line_packet
mode, there is no need to change to the new packet format.
However, if you wish to upgrade existing servers/clients to v2.0 safely, you must now pass the line_packet: true
option.
Here are some examples of adding the option for both server and client:
# Server option should be added to `opts`
JSONRPC2.Servers.TCP.start_listener(handler, port, name: name, line_packet: true)
JSONRPC2.Servers.TCP.child_spec(handler, port, name: name, line_packet: true)
# Client option should be added to `client_opts`
JSONRPC2.Clients.TCP.start(host, port, name, line_packet: true)
Why?
The line-terminated packet format caused the size of the packet to be limited by the size of the socket's receive buffer, causing difficult to diagnose errors when the packet size passed the limit.
The only downside of the new approach is a 4-byte overhead due to a new header indicating the size of the rest of the packet.
In light of the fact that the smallest possible JSON-RPC 2.0 request is approximately 50 bytes, I have decided to make this format the new default in an attempt to follow the principle of least surprise.
What if I want to switch to the new packet format, and uptime is a concern?
Here's an example approach:
- Update to v2.0, add
line_packet: true
, and deploy. - Add a new server listener for each existing one, on a different port, without
line_packet: true
, and deploy. - Update clients to use the new port, remove
line_packet: true
, and deploy. - Remove the original server listener for each one you created, and deploy.
Other Changes
- Fixes to Cowboy child_spec
- Documentation fixes
- Dialyzer fixes
Thanks
Thanks to everyone who has contributed to the project!
@naps62, @whitered, @sashman, @ryanleecode, @nkmanolovsumup, @gabrielgiordan, @fredericandre, @pdobacz, and @dkataskin
v1.2.0
- The default request ID for the HTTP client has changed to the string
"0"
, rather than the integer value0
, to resolve issues with some degenerate server implementations. - You can now optionally pass a custom request ID as an argument to the HTTP client.
- Remove extraneous check that handler module is loaded at compile time in HTTP plug.
- Package generally updated for modern Elixir, official support for v1.3 dropped.
v1.1.1
JSONRPC2.Servers.HTTP.Plug
will now accept any content-type and attempt to parse it as json, but it also isPlug.Parsers
friendly. This should resolve recent issues around content-type-related request failure. If you have a chain of plugs, (such as in a Phoenix Endpoint or Plug Builder/Router), you should note thatPlug
only allows the body to be retrieved once, so you must mountPlug.Parsers
aboveJSONRPC2.Servers.HTTP.Plug
. If you do not, the body will be consumed byJSONRPC2.Servers.HTTP.Plug
and will be unavailable to plugs which are later in the chain.- Examples have been formatted and added to the formatter config
JSONRPC2.Clients.HTTP
now uses the "content-type" header "application/json" by default, but this is easily overridden to be no explicit header (the previous default) or another content typeJSONRPC2.Clients.TCP
will no longer providenil
as a pid for "notify" casts to shackle, and instead uses a dead processes PID so that messages sent as a result of a notify are discardedJSONRPC2.Server.Handler
updated to no longer useSystem.stacktrace/0
in a deprecated way- Allow
Poison
~> 4.0 - Require
Plug
~> 1.3 - Add some more tests and clean up ignorable dialyzer errors in intentionally broken test code
v1.1.0
- Add Cowboy 2 support
- Only return method not found when a handler callback for the given method is not found. Otherwise, method not found exceptions now result in an internal server error, and the exception is reraised.
- Handle both application/json and plain/text in HTTP server