| Age | Commit message (Collapse) | Author |
|---|
|
With help of spdxconv tool [1], we able to bulk update all files license
and copyright format to comply with SPDX formats.
[1] https://kilabit.info/project/spdxconv/
|
|
Instead of returning nil only, return the error to report the input
parameter back to the caller.
|
|
There are several reasons that why we move from github.com.
First, related to the name of package.
We accidentally name the package with "share" a common word in English
that does not reflect the content of repository.
By moving to other repository, we can rename it to better and unique
name, in this "pakakeh.go".
Pakakeh is Minang word for tools, and ".go" suffix indicate that the
repository related to Go programming language.
Second, supporting open source.
The new repository is hosted under sourcehut.org, the founder is known
to support open source, and all their services are licensed under AGPL,
unlike GitHub that are closed sources.
Third, regarding GitHub CoPilot.
The GitHub Terms of Service [1], allow any public content that are hosted
there granted them to parse the content.
On one side, GitHub helps and flourish the open source, but on another
side have an issues regarding scraping the copyleft license [2].
[1]: https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#4-license-grant-to-us
[2]: https://githubcopilotinvestigation.com
|
|
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
|
|
|
|
The realignment reduce the cost of the following struct,
* EndpointResponse: from 72 to 56 bytes (-16 bytes)
* RangePosition: from 48 to 24 bytes (-24 bytes)
* testCase in TestParseContentRange: from 24 to 16 bytes (-8 bytes)
|
|
The lib/parser has been deprecated.
|
|
The ParseMultipartRange parse the multipart/byteranges body or response
from HTTP Range request.
Each Content-Range position and body part in the multipart will be stored
under RangePosition.
|
|
For HTTP Server using HandleFS, the Range request is handled
automatically.
For other HTTP server, user can use the HandleRange function.
The HandleRange function handle [HTTP Range] request using "bytes" unit.
The body parameter contains the content of resource being requested that
accept Seek method.
If the Request method is not GET, or no Range in header request it will
return all the body [RFC7233 S-3.1].
The contentType is optional, if its empty, it will detected by
http.ResponseWriter during Write.
[HTTP Range]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests
[RFC7233 S-3.1]: https://datatracker.ietf.org/doc/html/rfc7233#section-3.1
# Conflicts:
# CHANGELOG.adoc
|
