lukeed/sirv

An optimized middleware & CLI application for serving static files~!

sirv

An optimized middleware & CLI application for serving static files~!

• sirv
  GitHub · Package
  The core module, returning a middleware function for use in Polka & Express-like frameworks.

• sirv-cli
  GitHub · Package
  The standalone CLI application, allowing for instant previews of static sites.

Benchmarks

All results are taken with the following command:

$ wrk -t8 -c100 -d10s http://localhost:$PORT/
#=> wrk -t8 -c100 -d10s http://localhost:8080

Note: Expand each section to view results 🤔

Programmatic

Running the /bench directory with Node.js v10.13.0

Compares sirv against serve-static, both of which require programmatic usage for use within existing Node servers.

GET "/" (200)

serve-static
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.15ms    2.13ms  41.84ms   93.56%
    Req/Sec     1.49k   231.02     1.78k    89.50%
  118927 requests in 10.03s, 35.61MB read
Requests/sec:  11862.86
Transfer/sec:      3.55MB

sirv (dev: false)
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.78ms  495.92us   9.50ms   64.76%
    Req/Sec     2.08k   112.73     2.42k    68.50%
  166152 requests in 10.02s, 34.38MB read
Requests/sec:  16586.47
Transfer/sec:      3.43MB

sirv (dev: true)
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    11.79ms    1.95ms  43.30ms   94.02%
    Req/Sec     1.02k   121.86     1.33k    91.25%
  81808 requests in 10.04s, 18.88MB read
Requests/sec:   8147.26
Transfer/sec:      1.88MB

GET "/asset.js" (200)

serve-static
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.12ms    1.39ms  22.96ms   92.01%
    Req/Sec     1.49k   174.69     2.06k    73.38%
  118413 requests in 10.02s, 34.89MB read
Requests/sec:  11816.18
Transfer/sec:      3.48MB

sirv (dev: false)
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.64ms  507.55us   9.45ms   68.96%
    Req/Sec     2.14k    86.26     2.30k    75.50%
  170225 requests in 10.02s, 34.42MB read
Requests/sec:  16996.46
Transfer/sec:      3.44MB

sirv (dev: true)
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     7.21ms  445.13us  12.04ms   85.69%
    Req/Sec     1.67k    52.53     1.81k    76.88%
  133246 requests in 10.02s, 30.12MB read
Requests/sec:  13302.37
Transfer/sec:      3.01MB

GET "/404.css" (404)

serve-static
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.49ms  814.94us  19.10ms   94.89%
    Req/Sec     3.48k   406.87     5.59k    95.03%
  278809 requests in 10.10s, 28.18MB read
  Non-2xx or 3xx responses: 278809
Requests/sec:  27593.95
Transfer/sec:      2.79MB

sirv (dev: false)
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.27ms  328.88us  11.86ms   90.68%
    Req/Sec     5.32k   390.13     6.26k    93.18%
  426843 requests in 10.10s, 43.15MB read
  Non-2xx or 3xx responses: 426843
Requests/sec:  42256.52
Transfer/sec:      4.27MB

sirv (dev: true)
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    24.06ms    1.63ms  52.42ms   97.02%
    Req/Sec   500.47     29.42   640.00     71.62%
  39989 requests in 10.04s, 4.04MB read
  Non-2xx or 3xx responses: 39989
Requests/sec:   3982.45
Transfer/sec:    412.25KB

CLI

Each command was run independently on Node 16.13.0

Compares sirv-cli against http-server, both of which are standalone CLI utilities.

GET "/" (200)

http-server :: Cache = YES
  $ http-server tests/public
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    18.32ms    4.08ms  69.85ms   89.77%
    Req/Sec   659.44     93.04   767.00     90.62%
  52614 requests in 10.03s, 29.30MB read
Requests/sec:   5247.35
Transfer/sec:      2.92MB


http-server :: Cache = NO
  $ http-server tests/public -c-1
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    18.89ms    4.58ms  73.49ms   89.99%
    Req/Sec   639.83    105.69   727.00     89.00%
  51052 requests in 10.03s, 29.55MB read
Requests/sec:   5091.65
Transfer/sec:      2.95MB


sirv-cli :: Cache = YES
  $ sirv tests/public
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.19ms    6.18ms 106.92ms   95.99%
    Req/Sec     1.59k   300.50     1.82k    89.75%
  126322 requests in 10.02s, 60.72MB read
Requests/sec:  12612.53
Transfer/sec:      6.06MB


sirv-cli :: Cache = NO
  $ sirv tests/public --dev
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    11.32ms    1.99ms  54.04ms   94.70%
    Req/Sec     1.07k   122.82     1.21k    90.00%
  85069 requests in 10.02s, 42.92MB read
Requests/sec:   8490.92
Transfer/sec:      4.28MB


sirv-cli :: Cache = YES :: Logs = NO
  $ sirv tests/public --no-logs
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     7.05ms    1.78ms  33.87ms   94.72%
    Req/Sec     1.72k   295.83     6.89k    93.38%
  137539 requests in 10.11s, 66.11MB read
Requests/sec:  13609.61
Transfer/sec:      6.54MB


sirv-cli :: Cache = NO :: Logs = NO
  $ sirv tests/public --no-logs --dev
---
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     9.49ms    2.10ms  44.24ms   94.50%
    Req/Sec     1.28k   175.71     1.45k    87.88%
  101753 requests in 10.02s, 51.33MB read
Requests/sec:  10157.38
Transfer/sec:      5.12MB

Notice

There is zero relationship between sirv.com and this module or its author.

License

MIT © Luke Edwards

sirv's Issues

Add option to sirv-cli to not clear the console buffer

First off, awesome work on sirv. I use it basically every day and love the simplicity. So nice not to have to implement a native http server for each project to get the near native performance ❤️

My typically use case is to add sirv (via sirv-cli) for testing production builds. e.g. in a package.json NPM script task which does a production build and then serves the build assets with sirv. Works great 👍

However, when sirv starts it clears the console buffer so I lose the ability to scroll back to see the build output. I find myself either stopping the build to see the output or running sirv in a separate console... but both these approaches are less than ideal. It would be useful to have a cli flag to disable clearing the console.

Not sure what the best option name would be, maybe something like -n, --no-clear?

Dev mode ignores dotfiles

If dev mode is enabled, dotfiles is ignored.

For example, a file named .foo.txt is served in dev mode even if dotfiles is set to false.

Is there a good way to transform responses?

This may be outside the scope of sirv, but I'd like to modify the response body on the way to the client. In this case, I have a mostly static JavaScript file that I'm bundling with Rollup but I'd like to do some simple string substitution on the final response to include some request-specific data.

I understand that sirv pipes a readable stream to the response but I can't for the life of me figure out how to modify the contents of the stream... any help would be much appreciated.

Thanks!

File not refreshing

Maybe I'm doing something wrong, but for some reason just running sirv with an index.html and a script file, I change my script file, refresh and the script does not update. I'm running v0.2.2, do I need a special flag? I guess I shouldn't since it's just a static need.

Options to specify assets paths

If an asset can not be resolved in a --single app, the whole app is requested instead.

Fix:
Allow an asset prefix, so sirv treats anything within the asset path as an asset.

Enable SPA mode

• Add -s, --single flag
  - [ ] Checks for index.html before setting opts.onNoMatch

Update FILES when reading from disk?

I might be missing something, but would it make sense to update the cached entry in FILES when going to disk in the request handler?

svgs not displaying in Chrome - mime type for *.svg files is incorrect

It looks like Chrome requires the mime-type to be set to image/svg+xml to display the image.

serve-static does this correctly.

File Compression

As a convenience, sirv-cli should compress your files on startup. This would happen only once, immediately before using tiny-glob to read & cache the files.

I'm 90% sure the compression would have to be file-by-file, rather than doing the entire directory at once. This is because we'd have to see if the foobar.{hash}.gz (or whatever) file exists first, and only produce a compressed version if it doesn't exist... otherwise ETag values would be wrong.

🤔 Maybe run tiny-glob first after all? Then do a lookup on the returned results. Then, either rerun tiny-glob (since it'll still have its CACHE handy) or append our compressed outputs to the original set.

The sirv module should also take a compress option. It won't do any compressing (since it's the runtime), but it'll prefer/look to serve the compressed file over the original.

Allowed Values:

• gzip (default)
• brotli
• zopfli

CLI Flags

• -c, --compress, 'Enable file compression with specified format', 'gzip'

Clients can cause the server to crash using malformed URLs

Found in v0.4.5, seems to be fixed in the next branch.

To reproduce:

1. Run npx sirv start
2. Visit http://localhost:5000/%

Traceback:

/<redacted>/node_modules/sirv/index.js:81
			let stats, file, uri=decodeURIComponent(req.path || req.pathname || parser(req).pathname);
			                     ^

URIError: URI malformed
    at decodeURIComponent (<anonymous>)
    at Server.cc (/<redacted>/node_modules/sirv/index.js:81:25)
    at Server.emit (events.js:327:22)
    at parserOnIncoming (_http_server.js:789:12)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:116:17)

Support for TLS?

It doesn't seem like sirv has support for serving over TLS. Is this something you're considering to add? If not, do you know of an alternative that does?

In any case, thanks for the great product!

Allow `--single` to be passed a path

The CLI's --single option should be able to be passed a path, which will be served as the catch-all response instead of the default index.html. Passing no value for the option can continue to mean what it does now.

Sync glob performance?

Hi - I noticed you're using require('tiny-glob/sync') -- are there any performance implications for using sync with high-quantity connections, versus async/promise?

totalist/sync and list take a pre argument but we do not expose it as an option

The list function takes three arguments:

• dir
• callback
• prefix

Current implementation in both master and next do not provide an option to pass the prefix to the list function.

Excessive number of livereloads for a single file update

If I edit a file in the public folder. Say, change a rem size in util.css, I get the following output from the terminal. Is that normal?

  [10:08:01] 200 ─ 1.06ms ─ /components.css?livereload=1570090081557
  [10:08:01] 200 ─ 1.25ms ─ /components.css?livereload=1570090081559
  [10:08:01] 200 ─ 8.09ms ─ /utils.css?livereload=1570090081558
  [10:08:01] 200 ─ 11.68ms ─ /utils.css?livereload=1570090081559
  [10:08:01] 200 ─ 0.50ms ─ /components.css?livereload=1570090081560
  [10:08:01] 200 ─ 3.93ms ─ /utils.css?livereload=1570090081560
  [10:08:01] 200 ─ 1.08ms ─ /components.css?livereload=1570090081561
  [10:08:01] 200 ─ 1.48ms ─ /utils.css?livereload=1570090081561
  [10:08:01] 200 ─ 3.09ms ─ /components.css?livereload=1570090081562
  [10:08:01] 200 ─ 0.55ms ─ /components.css?livereload=1570090081563
  [10:08:01] 200 ─ 4.05ms ─ /components.css?livereload=1570090081564
  [10:08:01] 200 ─ 10.16ms ─ /utils.css?livereload=1570090081562
  [10:08:01] 200 ─ 2.39ms ─ /utils.css?livereload=1570090081563
  [10:08:01] 200 ─ 6.51ms ─ /utils.css?livereload=1570090081564

The files are all exactly the same, respectively.

Support for SPA in CLI?

Is there a way to enable SPA (e.g. send all non-file requests to index.html) by default in the CLI?

If there is no such an option, perhaps a flag like --spa or -s would help a lot (although I think it should be enabled by default, without flags).

Static Assets not served properly in --single mode at nested routes

First of all, thank you, @lukeed for all of your projects and contributions. I really appreciate it.

Here's my issue:
I am working in a Svelte project, which is using rollup and sirv-cli in dev mode to serve up my stuff. I am using a js router, so I used -s to serve up index.html for every document request.

package.json

"scripts": {
  ...
  "start:dev": "sirv public --dev -s"
}

Unfortunately, when I visit a /sub/sub route (2 levels or deeper) and then refresh the page (or if live reload does it for me, same result either way), the index.html gets served as expected, but the other static assets are not being located properly. Here is the output from 2 requests, so you can see the issue is that the sub-route is being kept in the url for the asset requests any time the url has 2 or more levels of subroutes in it (1 is fine though).

(request 1 => /workspaces)
  [00:38:54] 200 ─ 10.45ms ─ /workspaces  <= delivers /index.html properly
  [00:38:54] 200 ─ 3.33ms ─ /bundle.css
  [00:38:54] 200 ─ 12.29ms ─ /global.css
  [00:38:54] 200 ─ 2.52ms ─ /bundle.js    <= also delivers js properly
  [00:38:55] 200 ─ 2.70ms ─ /bundle.js.map
  [00:38:55] 200 ─ 0.43ms ─ /bundle.css.map
  [00:38:55] 200 ─ 1.12ms ─ /favicon.png

(request 2 has second level of sub route => /workspaces/2)
  [00:40:25] 200 ─ 0.81ms ─ /workspaces/favicon.png
  [00:40:28] 200 ─ 0.57ms ─ /workspaces/2            <= successfully delivers /index.html
  [00:40:28] 200 ─ 2.96ms ─ /workspaces/global.css
  [00:40:28] 200 ─ 3.31ms ─ /workspaces/bundle.css
  [00:40:28] 200 ─ 0.77ms ─ /workspaces/bundle.js    <= can't find my js
  [00:40:28] 200 ─ 0.67ms ─ /workspaces/favicon.png

Am I doing something wrong, or is this a valid issue with the package?

(sirv-cli) https & http at the same time when `--single`?

THANK YOU first and foremost for the latest update, I've been banging my head against the wall trying to get certs working locally for https and thought I needed to use http-server or servor or something but I just noticed your release yesterday and low and behold it's running https now, THANK YOU!!!

So, should sirv --single respond to http AND https simultaneously? My local one is not responding to http calls when I spin it up like this:

sirv dist --dev --host 0.0.0.0 --single --http2 --key key.pem --cert cert.pem

I can put multiple commands in place to address it but would appreciate it responding to both consistently.

browser refresh for https://localhost:5000/home (--single is working)

browser refresh for http://localhost:5000/home (--single is NOT working?)

--maxage option not working?

I have the following in package.json:

"start:dev": "sirv public --single --dev --host 0 --port 8080 -m 0"

However, the response headers lack cache-control. Is this a bug or did I misunderstand the usage of -m/--maxage?

On a related note, wouldn't it make sense to always pass a no cache header in dev mode?

Add option to bind host to 0.0.0.0

Hello Luke,

I wanted to try out the Svelte project which uses the sirv-cli as development server. I generally run my development environments from within Docker containers which require that a server bind to host 0.0.0.0. Otherwise, my browser is unable to connect to the development server.

I tried using the --cors option to get past this issue but it didn't work. Am I perhaps missing something? Is it possible to bind your current implementation with an undocumented option?

Unfortunately, I had to switch over to a different development server but would like to use the recommend one.

Thank you for your time and awesome package.

Any relation to sirv.com?

sirv.com is a CDN for serving static images. Given that this project is also related to serving static images I thought I'd check to see if there's any relationship between the two. It might be good to call it out on the README either way

Provide a "304 not modified" options

In order to generate this kind of response: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304

Is it a good idea?

Any plan to have live reload feature?

Like, run from cli.

Cannot set property 'statusCode' of undefined

Many times when I open my browser waiting for the sirv server to start it gives an error like this in console:

rollup v1.14.4
bundles src/main.js → dist...
LiveReload enabled
C:\project\node_modules\sirv-cli\boot.js:40
                opts.onNoMatch = (req, res) => (req.path='/',fn(req, res, r => (r.statusCode=404,r.end())));
                                                                                            ^

TypeError: Cannot set property 'statusCode' of undefined
    at r (C:\project\node_modules\sirv-cli\boot.js:40:79)
    at C:\project\node_modules\sirv\index.js:93:18
    at opts.onNoMatch (C:\project\node_modules\sirv-cli\boot.js:40:48)
    at Server.<anonymous> (C:\project\node_modules\sirv\index.js:93:27)
    at Server.emit (events.js:203:15)
    at parserOnIncoming (_http_server.js:677:12)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:109:17)

I'm using sveltejs/template (rollup one)

and running from a package.json script like this:

"start:dev": "sirv dist --dev -s".

If I close my browser page and try to re-run everything works again!

Major version bump to 1.0

Please consider following semver, it doesn't mean the project is suddenly 'done' or has changed. It just gives users context about the change and reliability that patch and minor changes won't break their code base.

As Stephan Bönnemann (who is arguing hard for semver and did talks on the subject), loosely quoted:

Version numbers should be used to avoid dependency hell... There's no reason for keeping the version number low, expect for marketing or maybe emotional attachment to versions. There's this concept in our mind that the version number has something to say about the project or the process or the stability and all of this is wrong... People believe something incredible existing is happening when a major/breaking version is released...

Please consider this.

Include well-known locations by default

Disallowing requests to dotfiles is a good default, however, it also disallows requests to “well-known locations” as specified by RFC5785. /.well-known/ services are becoming increasingly more common and it would be helpful to include them by default.

There’s a similar issue over at expressjs/serve-static#54.

Allow `setHeaders` while using dev mode

I have a use-case where even in dev mode I need specific headers to be set, as a result I'm using prod mode but restarting node when FS changes are detected.

Would adding setHeaders into dev mode be a huge burden?

Feature: Use with folder partitioning

I wonder if I could use this static file middleware for my situation.
I need to store file uploads in a folder called blobs and since I expect a lot of files they should not be stored in the same directory. Instead I want to partition the blobs directory with 3 subdirectories based on the files content hash:

blobs/hash{0,3}/hash{3,6}/hash{6,9}/hash.ext

requests the like /hash should then fetch the file from this partitioned directory.
Also after creating the file I'd like to immediately update the sirv cache with this new file. Precompressing the file to .gz and brotli would be nice too.

Any ideas if that could be accomplished?

Documentation: --dev option not mentioned in README.

The --dev option is not mentioned in the README (GH and NPM sites), and only shows up when doing --help in CLI. Please document the --dev option for completeness.

Help with sirv in sapper apps

Hi, I just audited my app with Lighthouse and it says that my static resources needs an efficient caching policy. For example, by setting the header max-Age TTL header.

Effectively, I'm seeing all my assets (images, fonts) with no-cache header set.

Is there a way I need to configure sirv Middleware to fix this?

Several parameters with "public sirv --single"

Hello,

I'm using SvelteJS with "sirv public --single".

http://localhost:5000/ works fine.

http://localhost:5000/blog works fine.

http://localhost:5000/blog/1 works fine, only during a user action on the current page. If I modify the second parameter directly from the URL or if I click on a link from another website, the page goes blank and the error "Uncaught SyntaxError: Unexpected token '<'" is displayed in the console.

I do not have these problems with http://localhost:5000/blog for example.

Do you have a solution please?

package.json

{
    "name": "svelte-app",
    "version": "1.0.0",
    "scripts": {
        "build": "npm install && rollup -c",
        "dev": "npm install && rollup -c -w",
        "build_sass": "npm run build && sass --style=compressed ./src/global.scss ./public/build/global.css",
        "dev_sass": "npm run dev & sass --style=compressed --watch ./src/global.scss ./public/build/global.css",
        "start": "sirv public --single"
    },
    "devDependencies": {
        "@rollup/plugin-node-resolve": "^7.1.1",
        "rollup": "^1.31.0",
        "rollup-plugin-commonjs": "^10.1.0",
        "rollup-plugin-livereload": "^1.0.4",
        "rollup-plugin-svelte": "^5.1.1",
        "rollup-plugin-terser": "^5.2.0",
        "sass": "^1.25.0",
        "svelte": "^3.18.2",
        "svelte-preprocess": "^3.4.0"
    },
    "dependencies": {
        "page": "^1.11.5",
        "sirv-cli": "^1.0.0-next.3"
    }
}

routes.js

import Home from "./pages/Home.page.svelte";
import Blog from "./pages/Blog.page.svelte";
import NotFound from "./pages/NotFound.page.svelte";

export default [
    {
        path: "/",
        page: Home
    },
    {
        path: "/blog",
        page: Blog
    },
    {
        path: "/blog/:id",
        page: Blog
    },
    {
        path: "*",
        page: NotFound
    }
];

App.svelte

<script>
    import router from "page";
    import routes from "./routes.js";

    let page;
    let params;

    // @see https://github.com/visionmedia/page.js
    // @see https://jackwhiting.co.uk/posts/setting-up-routing-in-svelte-with-pagejs/
    // @see https://jackwhiting.co.uk/posts/refactoring-our-router-within-svelte/
    // @see https://codesandbox.io/s/sveltepagejs-routing-example-pckm7
    routes.forEach(route => {
        router(
            route.path,

            (context, next) => {
                params = context.params;
                next();
            },

            () => {
                page = route.page;
            }
        );
    });

    router.start();
</script>

<header>
    <nav>
        <a href="/">Home</a>
        <a href="/blog">Blog</a>
        <a href="/blog/1">Article 1</a>
    </nav>
</header>

<main>
    <svelte:component this={page} params={params} />
</main>

Blog.page.svelte

<script>
    export let params;

    console.log("Params:", params);
</script>

<h1>Blog page</h1>

{#if "id" in params}
    <p>Article {params.id}</p>
{/if}

Accept Ranges: bytes

How easy would it be to add support for video range requests? If it's non-trivial then not to worry, thought I'd ask.
I am writing something that plays videos in HTML5 and noticed that url#t=[start_time][,end_time] wasn't working, and then realised that sirv didn't have Accept Ranges: bytes for the video content request although it was serving the file ok. Would be nice to have the feature but if it's not within the scope of this project then fair enough. Thank you.

Unexpected path in SPA mode

i pass in the --single option but it doesn't work what i expected, the full path should be global.css instead of /r1/r2/r3/global.css

sirv README still says polka returns a Promise from listen()

Hello! 👋

Was just trying to spin up a quick demo based on the code samples in sirv and quickly hit an error with polka().listen(). I can see in polka where listen() no longer returns a Promise, but this change wasn't reflected here. Just wanted to give you a heads up!

Thank you!

Unable to serve sub directory in windows

current version only able to serve file on root directory as the file separator in windows different with req.pathname

expected FILES mapping
{ "/img/logo.png": "public\\img\\logo.png'}
actually
{ "/img\\logo.png": "public\\img\\logo.png'}

Heroku

Did you ever succeed deploying a project to Heroku? Can't get to make it work:

2019-06-11T06:23:09.000000+00:00 app[api]: Build succeeded
2019-06-11T06:23:11.025480+00:00 heroku[web.1]: Starting process with command `npm start`
2019-06-11T06:23:13.261944+00:00 heroku[web.1]: State changed from starting to crashed
2019-06-11T06:23:13.156570+00:00 app[web.1]: 
2019-06-11T06:23:13.156598+00:00 app[web.1]: > [email protected] start /app
2019-06-11T06:23:13.156600+00:00 app[web.1]: > sirv public --port $PORT
2019-06-11T06:23:13.156602+00:00 app[web.1]: 
2019-06-11T06:23:13.163650+00:00 app[web.1]: sh: 1: sirv: not found
2019-06-11T06:23:13.168216+00:00 app[web.1]: npm ERR! file sh
2019-06-11T06:23:13.168662+00:00 app[web.1]: npm ERR! code ELIFECYCLE
2019-06-11T06:23:13.168665+00:00 app[web.1]: npm ERR! errno ENOENT
2019-06-11T06:23:13.168799+00:00 app[web.1]: npm ERR! syscall spawn

On my machine it does work. Even specifying path won't work:

package.json

    "start": "./node_modules/sirv-cli/index.js public --port $PORT",

2019-06-11T06:33:23.000000+00:00 app[api]: Build succeeded
2019-06-11T06:33:24.633920+00:00 heroku[web.1]: Starting process with command `npm start`
2019-06-11T06:33:26.825206+00:00 heroku[web.1]: State changed from starting to crashed
2019-06-11T06:33:26.835948+00:00 heroku[web.1]: State changed from crashed to starting
2019-06-11T06:33:26.803194+00:00 heroku[web.1]: Process exited with status 1
2019-06-11T06:33:26.689639+00:00 app[web.1]: 
2019-06-11T06:33:26.689658+00:00 app[web.1]: > [email protected] start /app
2019-06-11T06:33:26.689660+00:00 app[web.1]: > ./node_modules/sirv-cli/index.js public --port $PORT
2019-06-11T06:33:26.689662+00:00 app[web.1]: 
2019-06-11T06:33:26.703283+00:00 app[web.1]: sh: 1: ./node_modules/sirv-cli/index.js: not found
2019-06-11T06:33:26.707405+00:00 app[web.1]: npm ERR! file sh
2019-06-11T06:33:26.707610+00:00 app[web.1]: npm ERR! code ELIFECYCLE
2019-06-11T06:33:26.707772+00:00 app[web.1]: npm ERR! errno ENOENT
2019-06-11T06:33:26.708044+00:00 app[web.1]: npm ERR! syscall spawn

any ideas?

Issue loading CBOR binary files

Hello! I use CBOR binary files to load all of my JSON for artwork (parsed first from svg to json) - as it's much faster and smaller than using bloated JSON files. In case you are not familiar with CBOR, here is the link.

Using Svelte v2 and the 'npm run build' command in the package.json file - which uses

"rollup-plugin-serve": "^0.4.2",

The CBOR files all load correctly. But when I switched to Svelte v3, using the 'npm run build' which uses

"sirv-cli": "^0.4.0",

Now for all of the CBOR files I get a 404. To double check where the problem was, I closed the command window and tried using a server called Mongoose to load the base index.html file - and then under another localhost port I loaded my v3 app, and all of the CBOR files loaded correctly. Here is the screenshot of the 404 problem using sirv, from Chrome dev tools:

And here is using the older rollup plugin for Svelte v2

Please let me know if you need any more details! Thanks so much for your work on the new Svelte, it's an incredible tool.

URI encoding

When the requested file name contains a space or any other non-ASCII character, sirv searches the file named with the percent-encoded name, e.g. if /my file.txt is requested, then sirv searches a file named my%20file.txt, which is not what is expected in the file system.

This occurs both in dev mode and in normal mode.

It can be fixed by adding uri = decodeURI(uri) or uri = decodeURIComponent(uri) -- I’m not sure what variant should be used here.

More complete list of mime types for Content-Type header

Some file types, such as *.ico, are resulting with a null Content-Type header.

I noticed that the following is used:

const mime = require('mime/lite');

One could extend the supported mime types by calling define on mime/lite

const mime = require('mime/lite');
mime.define({
  'image/x-icon': ['ico'],
})

Is this the intended api to add mime types?

Is sirv-cli an alternative to http-server?

If so – mention in the readme?

TypeScript types

Would you be open to a rewrite in TypeScript? Or including .d.ts files that specify the types?

Enable HTTP/2 default

Initially, sirv was meant to be a HTTP/2 server from the start, but there were some issues in setting this up. I think a lot of it may have to do with my incomplete knowledge of the H2 protocol, but in the early versions, I was seeing zero performance gain and, in some cases, saw worse performance. This is why I tabled it & sirv is now a(nother) HTTP/1 module.

This is relatively high priority. Because it requires Node 8 for the http2 module, this will also be a breaking change.

My plan of attack is to get sirv (as http) stable on 1.0 first. The http2 version can be made available on the next branch & npm tag until it's ready to become 2.0. At that point, I'll feel confident (enough) that it's done correctly this time around. 😅

---

Revisit 3849356 and ed6cf05 for initial attempt.

---

Module:

- [ ] Use createServer within sirv directly (again: 87b2d6d)
- [ ] Expect Buffer values for key & cert

• Lookup pushable assets from manifest via pathname

CLI Flags:

• --key, Path to SSL certificate key (Required)
• --cert, Path to SSL certificate file (Required)
• --cacert, Path to SSL certificate authority (Optional)
• -M --manifest, Path to HTTP/2 push manifest file

Keeping URL route whit SPA mode ?

Hello to all of u, first of all, really nice feature and lightweight also !

I'm actually doing a little JS application which deals with routes (as /items, /items/:id etc). I found out sirv had a Single Page option, but the behavior seems weird.

If i go to http://myurl.loc/test, sirv will automaticly redirect me on http://myurl.loc/

Have u any suggestion to make him behave more like a Rewrite rule to index more than a redirect behavior ?

Add option to disable call to `clear`

I run sirv with other processes via concurrently.

When sirv calls clear it scrolls the output of the other processes off the top of the screen.

SPA mode on non-cli mode

I saw that you added the SPA option on sirv-cli (commit), and I would like to know if it is also working on non-cli version.

Only half the image is served

I am trying to use sirv but I run into a problem where only half of some of my images is being served. I haven't change any of the options other than the "dev" option which value is false. I would like to know if there is a way for me to find out if the problem is sirv or something else.

Slow output for larger files

I tried to use sirv to deliver a moderately large JS file (~400kb) in dev environment, and noticed it had trouble handling it fast, even being static.

By opening it directly in browser, it took some seconds to load all its content. By fetching it via AJAX (my usage for this project) it also took the same time.

---

Edit:

Here is a sample file, but I believe it may happen with any other format.

How to use path prefix with sirv?

Thanks for great work. I am trying to use sirv with Polka and Sapper.

I have my public assets in folder 'public' and I want to reference those assets with path prefix say public/images/hero.jpg.

When I use Sirv as app.use(sirv('public')), I need to refer static assets as images/hero.jpg.
I am basically looking for something like app.use('/static', express.static(path.join(__dirname, 'public'))).

Failed reloading Vue's nested routes

I followed vue-router's nested routes.

I run sirv start --cors --single on the folder.

Clicking link-by-link worked.

Reloading http://localhost:5000/user worked.

Reloading http://localhost:5000/user/123 failed.

But Sirv logged that failed request as 200.

I wonder if this issue is related with Sirv.

Thanks Luke!

Option to auto generate self-signed TLS certificates

The next branch provides TLS support which is great, but we need to specify our own key and certificate file which can be cumbersome for development. Would there be any interest in adding pem for auto generating certificates? Maybe behind a --self-signed option.