2015-12-16 11:58:01 +02:00
|
|
|
// Copyright 2015 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 (
|
2016-02-02 19:29:54 +02:00
|
|
|
"bytes"
|
2017-03-22 20:20:33 +03:00
|
|
|
"context"
|
2016-02-02 19:29:54 +02:00
|
|
|
"encoding/json"
|
2017-11-17 15:18:46 +03:00
|
|
|
"errors"
|
2015-12-16 11:58:01 +02:00
|
|
|
"fmt"
|
2016-03-14 10:38:54 +02:00
|
|
|
"io"
|
2022-12-07 16:02:14 +03:00
|
|
|
"math"
|
2017-11-09 12:54:58 +03:00
|
|
|
"mime"
|
2015-12-16 11:58:01 +02:00
|
|
|
"net/http"
|
2020-08-03 15:08:42 +03:00
|
|
|
"net/url"
|
2022-12-07 16:02:14 +03:00
|
|
|
"strconv"
|
2016-07-12 18:47:15 +03:00
|
|
|
"sync"
|
|
|
|
"time"
|
2015-12-16 11:58:01 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
const (
|
2024-02-07 23:06:38 +03:00
|
|
|
defaultBodyLimit = 5 * 1024 * 1024
|
|
|
|
contentType = "application/json"
|
2015-12-16 11:58:01 +02:00
|
|
|
)
|
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// https://www.jsonrpc.org/historical/json-rpc-over-http.html#id13
|
|
|
|
var acceptedContentTypes = []string{contentType, "application/json-rpc", "application/jsonrequest"}
|
2016-07-12 18:47:15 +03:00
|
|
|
|
|
|
|
type httpConn struct {
|
|
|
|
client *http.Client
|
2020-08-03 15:08:42 +03:00
|
|
|
url string
|
2016-07-12 18:47:15 +03:00
|
|
|
closeOnce sync.Once
|
2019-11-18 11:40:59 +03:00
|
|
|
closeCh chan interface{}
|
2020-08-03 15:08:42 +03:00
|
|
|
mu sync.Mutex // protects headers
|
|
|
|
headers http.Header
|
2022-09-02 18:40:41 +03:00
|
|
|
auth HTTPAuth
|
2016-07-12 18:47:15 +03:00
|
|
|
}
|
|
|
|
|
2022-01-20 14:45:07 +03:00
|
|
|
// httpConn implements ServerCodec, but it is treated specially by Client
|
|
|
|
// and some methods don't work. The panic() stubs here exist to ensure
|
|
|
|
// this special treatment is correct.
|
|
|
|
|
2022-12-07 16:02:14 +03:00
|
|
|
func (hc *httpConn) writeJSON(context.Context, interface{}, bool) error {
|
2019-11-18 11:40:59 +03:00
|
|
|
panic("writeJSON called on httpConn")
|
2019-02-04 15:47:34 +03:00
|
|
|
}
|
|
|
|
|
2022-01-20 14:45:07 +03:00
|
|
|
func (hc *httpConn) peerInfo() PeerInfo {
|
|
|
|
panic("peerInfo called on httpConn")
|
|
|
|
}
|
|
|
|
|
2019-11-18 11:40:59 +03:00
|
|
|
func (hc *httpConn) remoteAddr() string {
|
2020-08-03 15:08:42 +03:00
|
|
|
return hc.url
|
2019-02-04 15:47:34 +03:00
|
|
|
}
|
|
|
|
|
2019-11-18 11:40:59 +03:00
|
|
|
func (hc *httpConn) readBatch() ([]*jsonrpcMessage, bool, error) {
|
|
|
|
<-hc.closeCh
|
2019-02-04 15:47:34 +03:00
|
|
|
return nil, false, io.EOF
|
2016-07-12 18:47:15 +03:00
|
|
|
}
|
|
|
|
|
2019-11-18 11:40:59 +03:00
|
|
|
func (hc *httpConn) close() {
|
|
|
|
hc.closeOnce.Do(func() { close(hc.closeCh) })
|
2019-02-04 15:47:34 +03:00
|
|
|
}
|
|
|
|
|
2019-11-18 11:40:59 +03:00
|
|
|
func (hc *httpConn) closed() <-chan interface{} {
|
|
|
|
return hc.closeCh
|
2015-12-16 11:58:01 +02:00
|
|
|
}
|
|
|
|
|
2018-07-31 12:16:14 +03:00
|
|
|
// HTTPTimeouts represents the configuration params for the HTTP RPC server.
|
|
|
|
type HTTPTimeouts struct {
|
|
|
|
// ReadTimeout is the maximum duration for reading the entire
|
|
|
|
// request, including the body.
|
|
|
|
//
|
|
|
|
// Because ReadTimeout does not let Handlers make per-request
|
|
|
|
// decisions on each request body's acceptable deadline or
|
|
|
|
// upload rate, most users will prefer to use
|
|
|
|
// ReadHeaderTimeout. It is valid to use them both.
|
|
|
|
ReadTimeout time.Duration
|
|
|
|
|
2022-08-03 17:50:12 +03:00
|
|
|
// ReadHeaderTimeout is the amount of time allowed to read
|
|
|
|
// request headers. The connection's read deadline is reset
|
|
|
|
// after reading the headers and the Handler can decide what
|
|
|
|
// is considered too slow for the body. If ReadHeaderTimeout
|
|
|
|
// is zero, the value of ReadTimeout is used. If both are
|
|
|
|
// zero, there is no timeout.
|
|
|
|
ReadHeaderTimeout time.Duration
|
|
|
|
|
2018-07-31 12:16:14 +03:00
|
|
|
// WriteTimeout is the maximum duration before timing out
|
|
|
|
// writes of the response. It is reset whenever a new
|
|
|
|
// request's header is read. Like ReadTimeout, it does not
|
|
|
|
// let Handlers make decisions on a per-request basis.
|
|
|
|
WriteTimeout time.Duration
|
|
|
|
|
|
|
|
// IdleTimeout is the maximum amount of time to wait for the
|
|
|
|
// next request when keep-alives are enabled. If IdleTimeout
|
|
|
|
// is zero, the value of ReadTimeout is used. If both are
|
|
|
|
// zero, ReadHeaderTimeout is used.
|
|
|
|
IdleTimeout time.Duration
|
|
|
|
}
|
|
|
|
|
|
|
|
// DefaultHTTPTimeouts represents the default timeout values used if further
|
|
|
|
// configuration is not provided.
|
|
|
|
var DefaultHTTPTimeouts = HTTPTimeouts{
|
2022-08-03 17:50:12 +03:00
|
|
|
ReadTimeout: 30 * time.Second,
|
|
|
|
ReadHeaderTimeout: 30 * time.Second,
|
|
|
|
WriteTimeout: 30 * time.Second,
|
|
|
|
IdleTimeout: 120 * time.Second,
|
2018-07-31 12:16:14 +03:00
|
|
|
}
|
|
|
|
|
2022-09-02 18:40:41 +03:00
|
|
|
// DialHTTP creates a new RPC client that connects to an RPC server over HTTP.
|
|
|
|
func DialHTTP(endpoint string) (*Client, error) {
|
|
|
|
return DialHTTPWithClient(endpoint, new(http.Client))
|
|
|
|
}
|
|
|
|
|
2018-01-24 11:59:15 +03:00
|
|
|
// DialHTTPWithClient creates a new RPC client that connects to an RPC server over HTTP
|
|
|
|
// using the provided HTTP Client.
|
2022-09-02 18:40:41 +03:00
|
|
|
//
|
|
|
|
// Deprecated: use DialOptions and the WithHTTPClient option.
|
2018-01-24 11:59:15 +03:00
|
|
|
func DialHTTPWithClient(endpoint string, client *http.Client) (*Client, error) {
|
2020-08-03 15:08:42 +03:00
|
|
|
// Sanity check URL so we don't end up with a client that will fail every request.
|
|
|
|
_, err := url.Parse(endpoint)
|
2015-12-16 11:58:01 +02:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
2022-09-02 18:40:41 +03:00
|
|
|
var cfg clientConfig
|
2023-01-12 13:04:34 +03:00
|
|
|
cfg.httpClient = client
|
2022-09-02 18:40:41 +03:00
|
|
|
fn := newClientTransportHTTP(endpoint, &cfg)
|
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
|
|
|
return newClient(context.Background(), &cfg, fn)
|
2022-09-02 18:40:41 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
func newClientTransportHTTP(endpoint string, cfg *clientConfig) reconnectFunc {
|
|
|
|
headers := make(http.Header, 2+len(cfg.httpHeaders))
|
2020-08-03 15:08:42 +03:00
|
|
|
headers.Set("accept", contentType)
|
|
|
|
headers.Set("content-type", contentType)
|
2022-09-02 18:40:41 +03:00
|
|
|
for key, values := range cfg.httpHeaders {
|
|
|
|
headers[key] = values
|
|
|
|
}
|
2015-12-16 11:58:01 +02:00
|
|
|
|
2022-09-02 18:40:41 +03:00
|
|
|
client := cfg.httpClient
|
|
|
|
if client == nil {
|
|
|
|
client = new(http.Client)
|
|
|
|
}
|
|
|
|
|
|
|
|
hc := &httpConn{
|
|
|
|
client: client,
|
|
|
|
headers: headers,
|
|
|
|
url: endpoint,
|
|
|
|
auth: cfg.httpAuth,
|
|
|
|
closeCh: make(chan interface{}),
|
|
|
|
}
|
|
|
|
|
|
|
|
return func(ctx context.Context) (ServerCodec, error) {
|
|
|
|
return hc, nil
|
|
|
|
}
|
2018-01-24 11:59:15 +03:00
|
|
|
}
|
|
|
|
|
2016-07-12 18:47:15 +03:00
|
|
|
func (c *Client) sendHTTP(ctx context.Context, op *requestOp, msg interface{}) error {
|
|
|
|
hc := c.writeConn.(*httpConn)
|
|
|
|
respBody, err := hc.doRequest(ctx, msg)
|
|
|
|
if err != nil {
|
2015-12-16 11:58:01 +02:00
|
|
|
return err
|
|
|
|
}
|
2021-04-21 16:51:30 +03:00
|
|
|
defer respBody.Close()
|
|
|
|
|
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
|
|
|
var resp jsonrpcMessage
|
|
|
|
batch := [1]*jsonrpcMessage{&resp}
|
|
|
|
if err := json.NewDecoder(respBody).Decode(&resp); err != nil {
|
2016-07-12 18:47:15 +03:00
|
|
|
return err
|
|
|
|
}
|
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
|
|
|
op.resp <- batch[:]
|
2016-07-12 18:47:15 +03:00
|
|
|
return nil
|
|
|
|
}
|
2015-12-16 11:58:01 +02:00
|
|
|
|
2016-07-12 18:47:15 +03:00
|
|
|
func (c *Client) sendBatchHTTP(ctx context.Context, op *requestOp, msgs []*jsonrpcMessage) error {
|
|
|
|
hc := c.writeConn.(*httpConn)
|
|
|
|
respBody, err := hc.doRequest(ctx, msgs)
|
2015-12-16 11:58:01 +02:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2016-07-12 18:47:15 +03:00
|
|
|
defer respBody.Close()
|
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
|
|
|
|
|
|
|
var respmsgs []*jsonrpcMessage
|
2016-07-12 18:47:15 +03:00
|
|
|
if err := json.NewDecoder(respBody).Decode(&respmsgs); err != nil {
|
2015-12-16 11:58:01 +02:00
|
|
|
return err
|
|
|
|
}
|
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
|
|
|
op.resp <- respmsgs
|
2016-07-12 18:47:15 +03:00
|
|
|
return nil
|
2015-12-16 11:58:01 +02:00
|
|
|
}
|
|
|
|
|
2016-07-12 18:47:15 +03:00
|
|
|
func (hc *httpConn) doRequest(ctx context.Context, msg interface{}) (io.ReadCloser, error) {
|
|
|
|
body, err := json.Marshal(msg)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2023-01-24 12:12:25 +03:00
|
|
|
req, err := http.NewRequestWithContext(ctx, http.MethodPost, hc.url, io.NopCloser(bytes.NewReader(body)))
|
2020-08-03 15:08:42 +03:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2016-07-12 18:47:15 +03:00
|
|
|
req.ContentLength = int64(len(body))
|
2022-05-16 12:59:35 +03:00
|
|
|
req.GetBody = func() (io.ReadCloser, error) { return io.NopCloser(bytes.NewReader(body)), nil }
|
2015-12-16 11:58:01 +02:00
|
|
|
|
2020-08-03 15:08:42 +03:00
|
|
|
// set headers
|
|
|
|
hc.mu.Lock()
|
|
|
|
req.Header = hc.headers.Clone()
|
|
|
|
hc.mu.Unlock()
|
2022-11-16 17:22:12 +03:00
|
|
|
setHeaders(req.Header, headersFromContext(ctx))
|
|
|
|
|
2022-09-02 18:40:41 +03:00
|
|
|
if hc.auth != nil {
|
|
|
|
if err := hc.auth(req.Header); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
}
|
2020-08-03 15:08:42 +03:00
|
|
|
|
|
|
|
// do request
|
2017-03-22 20:20:33 +03:00
|
|
|
resp, err := hc.client.Do(req)
|
2016-07-12 18:47:15 +03:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-04-19 16:32:43 +03:00
|
|
|
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
|
2021-04-21 16:51:30 +03:00
|
|
|
var buf bytes.Buffer
|
|
|
|
var body []byte
|
|
|
|
if _, err := buf.ReadFrom(resp.Body); err == nil {
|
|
|
|
body = buf.Bytes()
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil, HTTPError{
|
|
|
|
Status: resp.Status,
|
|
|
|
StatusCode: resp.StatusCode,
|
|
|
|
Body: body,
|
|
|
|
}
|
2018-04-19 16:32:43 +03:00
|
|
|
}
|
2016-07-12 18:47:15 +03:00
|
|
|
return resp.Body, nil
|
2015-12-16 11:58:01 +02:00
|
|
|
}
|
2016-02-24 12:19:00 +02:00
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// httpServerConn turns a HTTP connection into a Conn.
|
|
|
|
type httpServerConn struct {
|
2016-02-24 12:19:00 +02:00
|
|
|
io.Reader
|
|
|
|
io.Writer
|
2019-02-04 15:47:34 +03:00
|
|
|
r *http.Request
|
2016-02-24 12:19:00 +02:00
|
|
|
}
|
|
|
|
|
2024-02-07 23:06:38 +03:00
|
|
|
func (s *Server) newHTTPServerConn(r *http.Request, w http.ResponseWriter) ServerCodec {
|
|
|
|
body := io.LimitReader(r.Body, int64(s.httpBodyLimit))
|
2019-02-04 15:47:34 +03:00
|
|
|
conn := &httpServerConn{Reader: body, Writer: w, r: r}
|
2022-12-07 16:02:14 +03:00
|
|
|
|
|
|
|
encoder := func(v any, isErrorResponse bool) error {
|
|
|
|
if !isErrorResponse {
|
|
|
|
return json.NewEncoder(conn).Encode(v)
|
|
|
|
}
|
|
|
|
|
|
|
|
// It's an error response and requires special treatment.
|
|
|
|
//
|
|
|
|
// In case of a timeout error, the response must be written before the HTTP
|
|
|
|
// server's write timeout occurs. So we need to flush the response. The
|
|
|
|
// Content-Length header also needs to be set to ensure the client knows
|
|
|
|
// when it has the full response.
|
|
|
|
encdata, err := json.Marshal(v)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
w.Header().Set("content-length", strconv.Itoa(len(encdata)))
|
|
|
|
|
|
|
|
// If this request is wrapped in a handler that might remove Content-Length (such
|
|
|
|
// as the automatic gzip we do in package node), we need to ensure the HTTP server
|
|
|
|
// doesn't perform chunked encoding. In case WriteTimeout is reached, the chunked
|
|
|
|
// encoding might not be finished correctly, and some clients do not like it when
|
|
|
|
// the final chunk is missing.
|
|
|
|
w.Header().Set("transfer-encoding", "identity")
|
|
|
|
|
|
|
|
_, err = w.Write(encdata)
|
|
|
|
if f, ok := w.(http.Flusher); ok {
|
|
|
|
f.Flush()
|
|
|
|
}
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
dec := json.NewDecoder(conn)
|
|
|
|
dec.UseNumber()
|
|
|
|
|
|
|
|
return NewFuncCodec(conn, encoder, dec.Decode)
|
2016-02-24 12:19:00 +02:00
|
|
|
}
|
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// Close does nothing and always returns nil.
|
|
|
|
func (t *httpServerConn) Close() error { return nil }
|
|
|
|
|
|
|
|
// RemoteAddr returns the peer address of the underlying connection.
|
|
|
|
func (t *httpServerConn) RemoteAddr() string {
|
|
|
|
return t.r.RemoteAddr
|
|
|
|
}
|
|
|
|
|
|
|
|
// SetWriteDeadline does nothing and always returns nil.
|
|
|
|
func (t *httpServerConn) SetWriteDeadline(time.Time) error { return nil }
|
|
|
|
|
2016-07-12 18:47:15 +03:00
|
|
|
// ServeHTTP serves JSON-RPC requests over HTTP.
|
2019-02-04 15:47:34 +03:00
|
|
|
func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
|
2017-11-16 14:51:06 +03:00
|
|
|
// Permit dumb empty requests for remote health-checks (AWS)
|
2017-12-12 21:12:32 +03:00
|
|
|
if r.Method == http.MethodGet && r.ContentLength == 0 && r.URL.RawQuery == "" {
|
2020-04-28 11:43:21 +03:00
|
|
|
w.WriteHeader(http.StatusOK)
|
2017-11-16 14:51:06 +03:00
|
|
|
return
|
|
|
|
}
|
2024-02-07 23:06:38 +03:00
|
|
|
if code, err := s.validateRequest(r); err != nil {
|
2017-11-17 15:18:46 +03:00
|
|
|
http.Error(w, err.Error(), code)
|
2017-11-09 12:54:58 +03:00
|
|
|
return
|
|
|
|
}
|
2022-01-20 14:45:07 +03:00
|
|
|
|
|
|
|
// Create request-scoped context.
|
|
|
|
connInfo := PeerInfo{Transport: "http", RemoteAddr: r.RemoteAddr}
|
|
|
|
connInfo.HTTP.Version = r.Proto
|
|
|
|
connInfo.HTTP.Host = r.Host
|
|
|
|
connInfo.HTTP.Origin = r.Header.Get("Origin")
|
|
|
|
connInfo.HTTP.UserAgent = r.Header.Get("User-Agent")
|
|
|
|
ctx := r.Context()
|
|
|
|
ctx = context.WithValue(ctx, peerInfoContextKey{}, connInfo)
|
|
|
|
|
2020-03-27 15:52:53 +03:00
|
|
|
// All checks passed, create a codec that reads directly from the request body
|
|
|
|
// until EOF, writes the response to w, and orders the server to process a
|
2017-11-16 14:51:06 +03:00
|
|
|
// single request.
|
2017-11-17 15:18:46 +03:00
|
|
|
w.Header().Set("content-type", contentType)
|
2024-02-07 23:06:38 +03:00
|
|
|
codec := s.newHTTPServerConn(r, w)
|
2019-11-18 11:40:59 +03:00
|
|
|
defer codec.close()
|
2019-02-04 15:47:34 +03:00
|
|
|
s.serveSingleRequest(ctx, codec)
|
2016-02-24 12:19:00 +02:00
|
|
|
}
|
|
|
|
|
2017-11-17 15:18:46 +03:00
|
|
|
// validateRequest returns a non-zero response code and error message if the
|
|
|
|
// request is invalid.
|
2024-02-07 23:06:38 +03:00
|
|
|
func (s *Server) validateRequest(r *http.Request) (int, error) {
|
2017-12-12 21:12:32 +03:00
|
|
|
if r.Method == http.MethodPut || r.Method == http.MethodDelete {
|
2017-11-17 15:18:46 +03:00
|
|
|
return http.StatusMethodNotAllowed, errors.New("method not allowed")
|
2017-11-17 15:07:11 +03:00
|
|
|
}
|
2024-02-07 23:06:38 +03:00
|
|
|
if r.ContentLength > int64(s.httpBodyLimit) {
|
|
|
|
err := fmt.Errorf("content length too large (%d>%d)", r.ContentLength, s.httpBodyLimit)
|
2017-11-17 15:18:46 +03:00
|
|
|
return http.StatusRequestEntityTooLarge, err
|
2017-11-17 15:07:11 +03:00
|
|
|
}
|
2018-12-14 13:08:11 +03:00
|
|
|
// Allow OPTIONS (regardless of content-type)
|
|
|
|
if r.Method == http.MethodOptions {
|
|
|
|
return 0, nil
|
|
|
|
}
|
|
|
|
// Check content-type
|
|
|
|
if mt, _, err := mime.ParseMediaType(r.Header.Get("content-type")); err == nil {
|
|
|
|
for _, accepted := range acceptedContentTypes {
|
|
|
|
if accepted == mt {
|
|
|
|
return 0, nil
|
|
|
|
}
|
|
|
|
}
|
2017-11-17 15:07:11 +03:00
|
|
|
}
|
2018-12-14 13:08:11 +03:00
|
|
|
// Invalid content-type
|
|
|
|
err := fmt.Errorf("invalid content type, only %s is supported", contentType)
|
|
|
|
return http.StatusUnsupportedMediaType, err
|
2017-11-17 15:07:11 +03:00
|
|
|
}
|
2022-12-07 16:02:14 +03:00
|
|
|
|
|
|
|
// ContextRequestTimeout returns the request timeout derived from the given context.
|
|
|
|
func ContextRequestTimeout(ctx context.Context) (time.Duration, bool) {
|
|
|
|
timeout := time.Duration(math.MaxInt64)
|
|
|
|
hasTimeout := false
|
|
|
|
setTimeout := func(d time.Duration) {
|
|
|
|
if d < timeout {
|
|
|
|
timeout = d
|
|
|
|
hasTimeout = true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if deadline, ok := ctx.Deadline(); ok {
|
|
|
|
setTimeout(time.Until(deadline))
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the context is an HTTP request context, use the server's WriteTimeout.
|
|
|
|
httpSrv, ok := ctx.Value(http.ServerContextKey).(*http.Server)
|
|
|
|
if ok && httpSrv.WriteTimeout > 0 {
|
|
|
|
wt := httpSrv.WriteTimeout
|
|
|
|
// When a write timeout is configured, we need to send the response message before
|
|
|
|
// the HTTP server cuts connection. So our internal timeout must be earlier than
|
|
|
|
// the server's true timeout.
|
|
|
|
//
|
|
|
|
// Note: Timeouts are sanitized to be a minimum of 1 second.
|
|
|
|
// Also see issue: https://github.com/golang/go/issues/47229
|
|
|
|
wt -= 100 * time.Millisecond
|
|
|
|
setTimeout(wt)
|
|
|
|
}
|
|
|
|
|
|
|
|
return timeout, hasTimeout
|
|
|
|
}
|