diff options
| author | Shulhan <ms@kilabit.info> | 2024-01-19 03:39:50 +0700 |
|---|---|---|
| committer | Shulhan <ms@kilabit.info> | 2024-01-24 00:07:18 +0700 |
| commit | eb2b4dbdeceb663b1ce29bc08cd5446ecf4c1f07 (patch) | |
| tree | cfeb884e2890d8f74c516eaad9e0bc7a8bbdce59 /lib/http/range_test.go | |
| parent | dbfc1583d77d300f8da8e2d3714fa1592dde09a0 (diff) | |
| download | pakakeh.go-eb2b4dbdeceb663b1ce29bc08cd5446ecf4c1f07.tar.xz | |
lib/http: refactoring Range request, limit content served by server
When server receive,
GET /big
Range: bytes=0-
and the requested resources is quite larger, where writing all content of
file result in i/o timeout, it is best practice [1][2] if the server
write only partial content and let the client continue with the
subsequent Range request.
In the above case, the server should response with,
HTTP/1.1 206 Partial content
Content-Range: bytes 0-<limit>/<size>
Content-Length: <limit>
Where limit is maximum packet that is reasonable [3] for most of the
client.
In this server we choose 8MB as limit.
[1]: https://stackoverflow.com/questions/63614008/how-best-to-respond-to-an-open-http-range-request
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=570755
[3]: https://docs.aws.amazon.com/whitepapers/latest/s3-optimizing-performance-best-practices/use-byte-range-fetches.html
Diffstat (limited to 'lib/http/range_test.go')
| -rw-r--r-- | lib/http/range_test.go | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/lib/http/range_test.go b/lib/http/range_test.go index 62da743e..10be878c 100644 --- a/lib/http/range_test.go +++ b/lib/http/range_test.go @@ -26,7 +26,7 @@ func TestParseMultipartRange(t *testing.T) { tdata *test.Data reader *bytes.Reader r *Range - pos RangePosition + pos *RangePosition vbyte []byte got strings.Builder ) |