| 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/
|
|
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 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
|
