Jsonrpc Server Handles Only Post Requests
You get the jsonrpc server handles only post requests error when sending GET calls. To fix it, change your client HTTP method to POST and include a JSON body. Teams often hit this wall when testing an RPC endpoint in a browser. A browser address bar always sends a GET request by default. Engineers also trigger this error when health checks probe the wrong path. Fixing the HTTP method gets your traffic moving again. Still, wide roles and shared keys still leave those POST actions open to misuse.
Kubernetes API Server Access + Read-Only Root Filesystem: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You get the jsonrpc server handles only post requests error when sending GET calls. To fix it, change your client HTTP method to POST and include a JSON body. Teams often hit this wall when testing an RPC endpoint in a browser. A browser address bar always sends a GET request by default. Engineers also trigger this error when health checks probe the wrong path. Fixing the HTTP method gets your traffic moving again. Still, wide roles and shared keys still leave those POST actions open to misuse.
Why a jsonrpc server handles only post requests
Remote procedure call protocols work very differently from standard REST APIs. In REST, the HTTP verb tells the host what action to take. You use GET to read data and POST to write new data. In JSON-RPC, the HTTP layer is just a simple transport pipe. Every single command lives inside the JSON payload body itself. That payload holds the method name, the input values, and a request identifier.
Because GET requests lack a standard body, the RPC service rejects them right away. The host expects a POST request with a JSON content header on every call. When a monitor, browser, or script sends a GET request, the service stops it. It returns the message that the jsonrpc server handles only post requests. To make a valid call, your app must send a POST request. It also needs to set the content type to JSON and pass a structured body.
How to fix client calls and health checks
First, check the tool or script that triggered the error message. If you tested the URL in a browser, switch to an API client tool. Set the request method to POST and add a valid JSON-RPC body. A safe test method usually asks the service for its status or version.
Second, check your load balancer and uptime monitor settings. Many cloud health checks send GET requests to the root path by default. If your RPC service sits at the root path, every health check will fail. Your logs will fill up with rejected GET messages every few seconds. You can fix this by pointing health checks to a dedicated status endpoint. If the service lacks a status path, update the monitor to send a POST call.
Kubernetes API Server Access + Read-Only Root Filesystem: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What transport checks solve and what they miss
Enforcing POST requests keeps broken traffic and simple browser probes out of your service. Together with TLS and API keys, it forms your basic outer defense. These native setup rules decide which apps or users can reach the port. They also make sure incoming requests match the basic protocol format.
Yet transport rules leave a major security gap open during live operations. Once a client sends a valid POST request with a valid key, the door opens. Because JSON-RPC puts every action on a single URL path, network rules are blind. A firewall only sees a POST call going to the main endpoint. It cannot tell a safe read method apart from a destructive admin method. Shared keys and broad roles let any approved caller run any method in the body. Moreover, if a response returns sensitive data like emails or card numbers, nothing rewrites those fields.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why do I see this error when opening my endpoint in a browser?
Pasting a URL into a browser address bar always sends an HTTP GET request. Your RPC service requires an HTTP POST request with a JSON payload body. Use an API testing tool to send a POST call instead.
Can I configure a JSON-RPC service to accept GET requests?
Some frameworks allow GET requests with encoded query strings, but this breaks standard practice. Putting RPC commands in URLs exposes sensitive inputs in server logs and browser history. Always keep RPC calls inside POST bodies.
How should load balancers check if a JSON-RPC service is healthy?
Point your load balancer to a separate health path that accepts simple GET calls. If your app only serves the RPC path, set the checker to send a POST request. Pass a safe read-only method in that test body.