2022-09-02 18:40:41 +03:00
|
|
|
// Copyright 2022 The go-ethereum Authors
|
|
|
|
// This file is part of the go-ethereum library.
|
|
|
|
//
|
|
|
|
// The go-ethereum library is free software: you can redistribute it and/or modify
|
|
|
|
// it under the terms of the GNU Lesser General Public License as published by
|
|
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
|
|
// (at your option) any later version.
|
|
|
|
//
|
|
|
|
// The go-ethereum library is distributed in the hope that it will be useful,
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
// GNU Lesser General Public License for more details.
|
|
|
|
//
|
|
|
|
// You should have received a copy of the GNU Lesser General Public License
|
|
|
|
// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
package rpc
|
|
|
|
|
|
|
|
import (
|
|
|
|
"net/http"
|
|
|
|
|
|
|
|
"github.com/gorilla/websocket"
|
|
|
|
)
|
|
|
|
|
|
|
|
// ClientOption is a configuration option for the RPC client.
|
|
|
|
type ClientOption interface {
|
|
|
|
applyOption(*clientConfig)
|
|
|
|
}
|
|
|
|
|
|
|
|
type clientConfig struct {
|
rpc: add limit for batch request items and response size (#26681)
This PR adds server-side limits for JSON-RPC batch requests. Before this change, batches
were limited only by processing time. The server would pick calls from the batch and
answer them until the response timeout occurred, then stop processing the remaining batch
items.
Here, we are adding two additional limits which can be configured:
- the 'item limit': batches can have at most N items
- the 'response size limit': batches can contain at most X response bytes
These limits are optional in package rpc. In Geth, we set a default limit of 1000 items
and 25MB response size.
When a batch goes over the limit, an error response is returned to the client. However,
doing this correctly isn't always possible. In JSON-RPC, only method calls with a valid
`id` can be responded to. Since batches may also contain non-call messages or
notifications, the best effort thing we can do to report an error with the batch itself is
reporting the limit violation as an error for the first method call in the batch. If a batch is
too large, but contains only notifications and responses, the error will be reported with
a null `id`.
The RPC client was also changed so it can deal with errors resulting from too large
batches. An older client connected to the server code in this PR could get stuck
until the request timeout occurred when the batch is too large. **Upgrading to a version
of the RPC client containing this change is strongly recommended to avoid timeout issues.**
For some weird reason, when writing the original client implementation, @fjl worked off of
the assumption that responses could be distributed across batches arbitrarily. So for a
batch request containing requests `[A B C]`, the server could respond with `[A B C]` but
also with `[A B] [C]` or even `[A] [B] [C]` and it wouldn't make a difference to the
client.
So in the implementation of BatchCallContext, the client waited for all requests in the
batch individually. If the server didn't respond to some of the requests in the batch, the
client would eventually just time out (if a context was used).
With the addition of batch limits into the server, we anticipate that people will hit this
kind of error way more often. To handle this properly, the client now waits for a single
response batch and expects it to contain all responses to the requests.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
Co-authored-by: Martin Holst Swende <martin@swende.se>
2023-06-13 14:38:58 +03:00
|
|
|
// HTTP settings
|
2022-09-02 18:40:41 +03:00
|
|
|
httpClient *http.Client
|
|
|
|
httpHeaders http.Header
|
|
|
|
httpAuth HTTPAuth
|
|
|
|
|
rpc: add limit for batch request items and response size (#26681)
This PR adds server-side limits for JSON-RPC batch requests. Before this change, batches
were limited only by processing time. The server would pick calls from the batch and
answer them until the response timeout occurred, then stop processing the remaining batch
items.
Here, we are adding two additional limits which can be configured:
- the 'item limit': batches can have at most N items
- the 'response size limit': batches can contain at most X response bytes
These limits are optional in package rpc. In Geth, we set a default limit of 1000 items
and 25MB response size.
When a batch goes over the limit, an error response is returned to the client. However,
doing this correctly isn't always possible. In JSON-RPC, only method calls with a valid
`id` can be responded to. Since batches may also contain non-call messages or
notifications, the best effort thing we can do to report an error with the batch itself is
reporting the limit violation as an error for the first method call in the batch. If a batch is
too large, but contains only notifications and responses, the error will be reported with
a null `id`.
The RPC client was also changed so it can deal with errors resulting from too large
batches. An older client connected to the server code in this PR could get stuck
until the request timeout occurred when the batch is too large. **Upgrading to a version
of the RPC client containing this change is strongly recommended to avoid timeout issues.**
For some weird reason, when writing the original client implementation, @fjl worked off of
the assumption that responses could be distributed across batches arbitrarily. So for a
batch request containing requests `[A B C]`, the server could respond with `[A B C]` but
also with `[A B] [C]` or even `[A] [B] [C]` and it wouldn't make a difference to the
client.
So in the implementation of BatchCallContext, the client waited for all requests in the
batch individually. If the server didn't respond to some of the requests in the batch, the
client would eventually just time out (if a context was used).
With the addition of batch limits into the server, we anticipate that people will hit this
kind of error way more often. To handle this properly, the client now waits for a single
response batch and expects it to contain all responses to the requests.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
Co-authored-by: Martin Holst Swende <martin@swende.se>
2023-06-13 14:38:58 +03:00
|
|
|
// WebSocket options
|
2023-10-03 10:23:19 +03:00
|
|
|
wsDialer *websocket.Dialer
|
|
|
|
wsMessageSizeLimit *int64 // wsMessageSizeLimit nil = default, 0 = no limit
|
rpc: add limit for batch request items and response size (#26681)
This PR adds server-side limits for JSON-RPC batch requests. Before this change, batches
were limited only by processing time. The server would pick calls from the batch and
answer them until the response timeout occurred, then stop processing the remaining batch
items.
Here, we are adding two additional limits which can be configured:
- the 'item limit': batches can have at most N items
- the 'response size limit': batches can contain at most X response bytes
These limits are optional in package rpc. In Geth, we set a default limit of 1000 items
and 25MB response size.
When a batch goes over the limit, an error response is returned to the client. However,
doing this correctly isn't always possible. In JSON-RPC, only method calls with a valid
`id` can be responded to. Since batches may also contain non-call messages or
notifications, the best effort thing we can do to report an error with the batch itself is
reporting the limit violation as an error for the first method call in the batch. If a batch is
too large, but contains only notifications and responses, the error will be reported with
a null `id`.
The RPC client was also changed so it can deal with errors resulting from too large
batches. An older client connected to the server code in this PR could get stuck
until the request timeout occurred when the batch is too large. **Upgrading to a version
of the RPC client containing this change is strongly recommended to avoid timeout issues.**
For some weird reason, when writing the original client implementation, @fjl worked off of
the assumption that responses could be distributed across batches arbitrarily. So for a
batch request containing requests `[A B C]`, the server could respond with `[A B C]` but
also with `[A B] [C]` or even `[A] [B] [C]` and it wouldn't make a difference to the
client.
So in the implementation of BatchCallContext, the client waited for all requests in the
batch individually. If the server didn't respond to some of the requests in the batch, the
client would eventually just time out (if a context was used).
With the addition of batch limits into the server, we anticipate that people will hit this
kind of error way more often. To handle this properly, the client now waits for a single
response batch and expects it to contain all responses to the requests.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
Co-authored-by: Martin Holst Swende <martin@swende.se>
2023-06-13 14:38:58 +03:00
|
|
|
|
|
|
|
// RPC handler options
|
|
|
|
idgen func() ID
|
|
|
|
batchItemLimit int
|
|
|
|
batchResponseLimit int
|
2022-09-02 18:40:41 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
func (cfg *clientConfig) initHeaders() {
|
|
|
|
if cfg.httpHeaders == nil {
|
|
|
|
cfg.httpHeaders = make(http.Header)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (cfg *clientConfig) setHeader(key, value string) {
|
|
|
|
cfg.initHeaders()
|
|
|
|
cfg.httpHeaders.Set(key, value)
|
|
|
|
}
|
|
|
|
|
|
|
|
type optionFunc func(*clientConfig)
|
|
|
|
|
|
|
|
func (fn optionFunc) applyOption(opt *clientConfig) {
|
|
|
|
fn(opt)
|
|
|
|
}
|
|
|
|
|
|
|
|
// WithWebsocketDialer configures the websocket.Dialer used by the RPC client.
|
|
|
|
func WithWebsocketDialer(dialer websocket.Dialer) ClientOption {
|
|
|
|
return optionFunc(func(cfg *clientConfig) {
|
|
|
|
cfg.wsDialer = &dialer
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2023-10-03 10:23:19 +03:00
|
|
|
// WithWebsocketMessageSizeLimit configures the websocket message size limit used by the RPC
|
|
|
|
// client. Passing a limit of 0 means no limit.
|
|
|
|
func WithWebsocketMessageSizeLimit(messageSizeLimit int64) ClientOption {
|
|
|
|
return optionFunc(func(cfg *clientConfig) {
|
|
|
|
cfg.wsMessageSizeLimit = &messageSizeLimit
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2022-09-02 18:40:41 +03:00
|
|
|
// WithHeader configures HTTP headers set by the RPC client. Headers set using this option
|
|
|
|
// will be used for both HTTP and WebSocket connections.
|
|
|
|
func WithHeader(key, value string) ClientOption {
|
|
|
|
return optionFunc(func(cfg *clientConfig) {
|
|
|
|
cfg.initHeaders()
|
|
|
|
cfg.httpHeaders.Set(key, value)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
// WithHeaders configures HTTP headers set by the RPC client. Headers set using this
|
|
|
|
// option will be used for both HTTP and WebSocket connections.
|
|
|
|
func WithHeaders(headers http.Header) ClientOption {
|
|
|
|
return optionFunc(func(cfg *clientConfig) {
|
|
|
|
cfg.initHeaders()
|
|
|
|
for k, vs := range headers {
|
|
|
|
cfg.httpHeaders[k] = vs
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
// WithHTTPClient configures the http.Client used by the RPC client.
|
|
|
|
func WithHTTPClient(c *http.Client) ClientOption {
|
|
|
|
return optionFunc(func(cfg *clientConfig) {
|
|
|
|
cfg.httpClient = c
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
// WithHTTPAuth configures HTTP request authentication. The given provider will be called
|
|
|
|
// whenever a request is made. Note that only one authentication provider can be active at
|
|
|
|
// any time.
|
|
|
|
func WithHTTPAuth(a HTTPAuth) ClientOption {
|
|
|
|
if a == nil {
|
|
|
|
panic("nil auth")
|
|
|
|
}
|
|
|
|
return optionFunc(func(cfg *clientConfig) {
|
|
|
|
cfg.httpAuth = a
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
// A HTTPAuth function is called by the client whenever a HTTP request is sent.
|
|
|
|
// The function must be safe for concurrent use.
|
|
|
|
//
|
|
|
|
// Usually, HTTPAuth functions will call h.Set("authorization", "...") to add
|
|
|
|
// auth information to the request.
|
|
|
|
type HTTPAuth func(h http.Header) error
|
rpc: add limit for batch request items and response size (#26681)
This PR adds server-side limits for JSON-RPC batch requests. Before this change, batches
were limited only by processing time. The server would pick calls from the batch and
answer them until the response timeout occurred, then stop processing the remaining batch
items.
Here, we are adding two additional limits which can be configured:
- the 'item limit': batches can have at most N items
- the 'response size limit': batches can contain at most X response bytes
These limits are optional in package rpc. In Geth, we set a default limit of 1000 items
and 25MB response size.
When a batch goes over the limit, an error response is returned to the client. However,
doing this correctly isn't always possible. In JSON-RPC, only method calls with a valid
`id` can be responded to. Since batches may also contain non-call messages or
notifications, the best effort thing we can do to report an error with the batch itself is
reporting the limit violation as an error for the first method call in the batch. If a batch is
too large, but contains only notifications and responses, the error will be reported with
a null `id`.
The RPC client was also changed so it can deal with errors resulting from too large
batches. An older client connected to the server code in this PR could get stuck
until the request timeout occurred when the batch is too large. **Upgrading to a version
of the RPC client containing this change is strongly recommended to avoid timeout issues.**
For some weird reason, when writing the original client implementation, @fjl worked off of
the assumption that responses could be distributed across batches arbitrarily. So for a
batch request containing requests `[A B C]`, the server could respond with `[A B C]` but
also with `[A B] [C]` or even `[A] [B] [C]` and it wouldn't make a difference to the
client.
So in the implementation of BatchCallContext, the client waited for all requests in the
batch individually. If the server didn't respond to some of the requests in the batch, the
client would eventually just time out (if a context was used).
With the addition of batch limits into the server, we anticipate that people will hit this
kind of error way more often. To handle this properly, the client now waits for a single
response batch and expects it to contain all responses to the requests.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
Co-authored-by: Martin Holst Swende <martin@swende.se>
2023-06-13 14:38:58 +03:00
|
|
|
|
|
|
|
// WithBatchItemLimit changes the maximum number of items allowed in batch requests.
|
|
|
|
//
|
|
|
|
// Note: this option applies when processing incoming batch requests. It does not affect
|
|
|
|
// batch requests sent by the client.
|
|
|
|
func WithBatchItemLimit(limit int) ClientOption {
|
|
|
|
return optionFunc(func(cfg *clientConfig) {
|
|
|
|
cfg.batchItemLimit = limit
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
// WithBatchResponseSizeLimit changes the maximum number of response bytes that can be
|
|
|
|
// generated for batch requests. When this limit is reached, further calls in the batch
|
|
|
|
// will not be processed.
|
|
|
|
//
|
|
|
|
// Note: this option applies when processing incoming batch requests. It does not affect
|
|
|
|
// batch requests sent by the client.
|
|
|
|
func WithBatchResponseSizeLimit(sizeLimit int) ClientOption {
|
|
|
|
return optionFunc(func(cfg *clientConfig) {
|
|
|
|
cfg.batchResponseLimit = sizeLimit
|
|
|
|
})
|
|
|
|
}
|