2019-02-23 13:47:59 +00:00
|
|
|
# HTTP resource pack server
|
|
|
|
|
2020-02-15 12:27:45 +00:00
|
|
|
[![GoDoc](https://img.shields.io/static/v1?label=godoc&message=reference&color=blue)](https://pkg.go.dev/src.lwithers.me.uk/go/htpack)
|
|
|
|
|
2019-02-23 13:47:59 +00:00
|
|
|
A common scenario is that you have a set of static resources that you want to
|
2019-03-05 18:41:02 +00:00
|
|
|
serve up quickly via HTTP (for example: stylesheets, WASM).
|
2019-02-23 13:47:59 +00:00
|
|
|
|
|
|
|
This package provides a `net/http`-compatible `http.Handler` to do so, with
|
|
|
|
support for:
|
|
|
|
- compression
|
|
|
|
- gzip
|
2020-02-15 11:22:05 +00:00
|
|
|
- brotli
|
2019-02-23 13:47:59 +00:00
|
|
|
- does not yet support Transfer-Encoding, only Accept-Encoding/Content-Encoding
|
|
|
|
- etags
|
2019-10-09 13:04:07 +01:00
|
|
|
- ranges
|
2019-02-23 13:47:59 +00:00
|
|
|
|
|
|
|
The workflow is as follows:
|
2019-03-08 09:16:25 +00:00
|
|
|
- (optional) build YAML file describing files to serve
|
2019-02-23 13:47:59 +00:00
|
|
|
- run htpacker tool to produce a single .htpack file
|
|
|
|
- create `htpack.Handler` pointing at .htpack file
|
|
|
|
|
2019-03-08 09:16:25 +00:00
|
|
|
The handler can easily be combined with middleware (`http.StripPrefix` etc.).
|
2019-10-09 13:04:07 +01:00
|
|
|
|
|
|
|
## Range handling notes
|
|
|
|
|
|
|
|
Too many bugs have been found with range handling and composite ranges, so the
|
|
|
|
handler only accepts a single range within the limits of the file. Anything
|
|
|
|
else will be ignored.
|
|
|
|
|
|
|
|
The interaction between range handling and compression also seems a little
|
|
|
|
ill-defined; as we have pre-compressed data, however, we can consistently
|
|
|
|
serve the exact same byte data for compressed files.
|
2020-02-15 12:26:01 +00:00
|
|
|
|
|
|
|
## Angular-style single-page application handling
|
|
|
|
|
|
|
|
If you wish to support an angular.js-style single page application, in which
|
|
|
|
a Javascript application uses the browser's history API to create a set of
|
|
|
|
virtual paths ("routes"), it is necessary to somehow intercept HTTP 404 errors
|
|
|
|
being returned from the handler and instead return an HTTP 200 with an HTML
|
|
|
|
document.
|
|
|
|
|
|
|
|
This can be achieved with a number of methods.
|
|
|
|
|
2020-02-15 12:31:42 +00:00
|
|
|
The simplest method is to tell `packserver` itself which resource to use
|
|
|
|
instead of returning an HTTP 404. Use the command line argument
|
|
|
|
`--fallback-404 /index.html` (or whichever named resource). The filename must
|
|
|
|
match a packed resource, so it will be preceded with a `/`. It must exist in
|
|
|
|
all packfiles being served.
|
|
|
|
|
2020-02-15 12:26:01 +00:00
|
|
|
If you have an nginx instance reverse proxying in front of `htpack`, then you
|
2020-02-15 12:31:42 +00:00
|
|
|
can use a couple of extra directives. This is very flexible as it lets you
|
|
|
|
override the resource for different routes. For example:
|
2020-02-15 12:26:01 +00:00
|
|
|
|
|
|
|
# prevent page loaded at "http://server.example/my-application" from
|
|
|
|
# requesting resources at "/*" when it should request them at
|
|
|
|
# "/my-application/*" instead
|
|
|
|
location = /my-application {
|
|
|
|
return 308 /my-application/;
|
|
|
|
}
|
|
|
|
|
|
|
|
location /my-application/ {
|
|
|
|
proxy_to http://htpack-addr:8080/;
|
|
|
|
proxy_intercept_errors on;
|
|
|
|
error_page 404 =200 /my-application/;
|
|
|
|
}
|
|
|
|
|
|
|
|
If you are using the handler as a library, then you may call
|
|
|
|
`handler.SetNotFound(filename)` to select a resource to return (with HTTP 200)
|
|
|
|
if a request is made for a resource that is not found. The filename must match
|
|
|
|
a packed resource, so it will be preceded with a `/` (for example it may be
|
|
|
|
`"/index.html"`).
|