jfhbrook/node-ecstatic

A static file server middleware that works with core http, express or on the CLI!

hello yes this is Josh 👋

Hi! I'm a staff engineer. My pronouns are he/him.

Where to Find Me

• Blog: https://dev.to/jfhbrook
• Resume: https://github.com/jfhbrook/resume
• LinkedIn: https://www.linkedin.com/in/jfhbrook/
• Twitter: https://twitter.com/jfhbrook
• Mastodon: https://oldbytes.space/@jfhbrook

My Code

The portal for my open source code may be found at https://github.com/jfhbrook/public.

node-ecstatic's Issues

Add API entry points for custom and async mime lookup

Hi, I'm trying to serve text files with unusual filename extensions, which wind up as octet-stream due to ecstatic's reliance on the "mime" module:

sven:/gr2$ nodejs -e 'console.log(require("mime").lookup("common.flp"));'
application/octet-stream

I'd prefer them to be resolved according to my local mime types DB:

sven:/gr2$ file --mime common.flp
common.flp: text/plain; charset=us-ascii

This could be achieved by using the "mime-magic" module:

sven:/gr2$ nodejs -e 'var mime = require("mime-magic"); mime("common.flp", console.log);'
null 'text/plain'

It seems that in the "mime" module, there's currently no way to distinguish known octet-streams from fallback octet-streams (mime bug #55).

I'd be glad if you could implement the mime-magic lookup into mainstream ecstatic.

(Edit 2015-12-08: The filename-based lookup is fine for default. If mime-magic lookup ever gets into mainstream ecstatic, only use it as a fallback for when filename-based mime has no idea.)

Problems when requesting files whose folder names have spaces

When requesting files whose folder names have spaces it will throw an error.
URL: http://localhost:8080/folder_with%20space
file: notes.txt

Suppose I request notes.txt from the index listing. When clicked it looks for:
http://localhost:8080/folder_with%2520space/notes.txt
and throws this error:
"Cannot GET /folder_with%2520space/notes.txt"

It looks like the server finds the % in the url request and tries to re-encode it with 25.

I noticed this from using http-server.

requesting /%00 triggers some weird bug that causes it to endless-loop or something like that

interesting.

Readme Issue

This text:

Serve /path/index.html when /path/ is requested. Turn off autoIndexing with opts.autoIndex === true. Defaults to true.

I believe should read:

Serve /path/index.html when /path/ is requested. Turn on autoIndexing with opts.autoIndex === true. Defaults to false.

include charset in Content-Type header

status 405 not check next

why status-handlers not check next? so in flatiron, post request is returned 405 in ecstatic, not to router

Attempting to visit an empty directory may cause an infinite loop.

See issues for http-server.

Organization

estatic has a lot of branching in it. It'd be nice to manage this "better".

Breaks in Union

This is because Union's stream piping is currently broken. :'(

Mapping Directories to specific URLs?

Instead of simply specifying a directory to expose to the root url, it would be nice if we could specify the url we want our static files on.

content-range for pause/resume of big files

I saw this implemented in connect.static, so ecstatic should probably have it too:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16

There's also If-Range, Accept-Ranges, and Range headers which might be related.

Etag

Implement the Etag header. It is a necessity for any static file server: https://github.com/cloudhead/node-static/blob/master/lib/node-static.js#L186-201

href is invalid when there is query string in url

Start ecstatic with --showDir, open this url:

http://localhost:8080/?key=value

The href's got ?key=value within, which is invalid.

http://localhost:8080/?key=value/folder%20with%20space/

Changing this in showdir.js:writeRow() will ignore the query string:

-                req.url.replace(/\/$/, '')
+                parsed.pathname.replace(/\/$/, '')

But the test 'malformed showdir uri' will then fail, I think this test is incorrect in putting the malformed string in the query.
The test failed incidentally in the first place because of this issue.

We already protect against invalid pathname in ecstatic.js:middleware(). We could check the query part by passing req.url there.

I would suggest checking req.url in ecstatic.js:middleware(), and test malformed string in both query and pathname in malformed-dir.js.

Status of responses is not respected in union

Because of ecstatic status handlers using:

if (typeof next === "function") {
    next();
}

and union using it's default error handler as

  (this.res || res).writeHead(404, {"Content-Type": "text/plain"});
  (this.res || res).end("Not Found\n");

almost every request that passes through ecstatic and end in any status other than 200 or 500, ends up in union's default error handler, ending in an error 404.

It would be useful to have a option to define a html file to display in case of specific error codes (as the 404.html file for 404 errors) to be able to remove the next() statements from the status handlers and so be able to keep the intended error codes (for example, a 403 when trying to access a directory with showDir = false)

Ensure 304's actually work

At one point in time, 304's weren't being set. Our fix at the time was to use res.writeHead instead of setting res.statusCode. This seems wrong, though.

One user commented on the issue after its closure:

#25 (comment)

I have a feeling this mostly works in master, though I need to make sure there are tests for it.

Live Code Examples Don't Work

Runnable.com doesn't show me an error, just renders their homepage instead (doesn't redirect/update URI though).

backport config API from 0.2.x branch to master

all args should be in an options hash.

next() vs. res.emit("next")

There is some behavior that checks for the existence of "next". I don't think this will cause problems with union's res.emit("next") since the function next is shimmed out.

Just something to watch out for.

404 With defaultExt and URL query params.

This bit of code creates an invalid file path:

        else if (defaultExt && !path.extname(req.url).length) {
          //
          // If no file extension is specified and there is a default extension
          // try that before rendering 404.html.
          //
          middleware({
            url: req.url + '.' + defaultExt
          }, res, next);
        }

results in "/my/url/path?foo=bar.html"

https://github.com/jesusabdullah/node-ecstatic/blob/master/lib/ecstatic.js#L81-L89

Custom file for 404 error

Hi,

Is there any way to specify custom files for 404 errors?

Moar betters directory view

For someone to really navigate a directory structure using ecstatic, there needs to be a way to easily go "up" one directory.
See this page, which contains a screenshot of the style that Apache follows when encountering static directories/files: http://www.daftlogic.com/information-stop-apache-listing-directories.htm

In general, it'd be nice to see the output of the Linux command "ls -l" for the directory that we're currently looking at.

make sure subdir 302's to subdir/

nt

showDir serves up broken links for files with special characters

I'm displaying a directory tree within my Express app with the sample code listed on the project's main page:
app.use(ecstatic(__dirname + '/share'));
This works fine for most of the files under the share directory tree.
However, I have some directories whose names contain spaces (not my typical naming style in Linux, but since these names will be visible through my site, I want them to be more readable), and while these directories display correctly (the spaces are converted to "%20"s in the URL, I can't access files within these directories - I get the default Express error "Cannot GET /[path]/[file]" error.

I've tested several cases with spaces in file and/or directory names:

• File names with spaces in them - open properly
• Directory names with spaces in them - display properly
• File names without spaces in them, inside directories whose names have spaces in them - "Cannot GET" error
• File names with spaces in them, inside directories whose names have spaces in them - "Cannot GET" error

backport gzip support to master branch

See: #36

No regard for security

For example, you can path traverse however you want.

ecstatic not working on windows

in file ecstatic.js, you initialize root var with a '/' at the end.

  var root = path.resolve(dir) + '/',

In windows it makes following test always wrong:

 if (file.slice(0, root.length) !== root) {

eg: file is c:\test\project\public\index.html and root is c:\test\project\public/
=> file.slice(0, root.length) = c:\test\project\public\ and root = c:\test\project\public/

Is trailing slash on root really necessary?

When I remove it, it works.

configuration?

A bunch of things need to be exposed as options.

querystring lost on default autoIndex returns

The issue: requesting /foo?params=bar the url becomes /foo

I notice that requesting /foo/index.html?params=bar the querystring stays.

The issue is that i would like for the querystring to persist in through the request, so that you could say, bookmark/share/etc...Think the issue may be in path.normalize.

Feature request: gzip support

I want to use ecstatic for a project which helps build client side apps. Part of this project gzip's assets, however, ecstatic doesn't currently check the Accept-Encoding header to see if the client accepts gzip/compressed resources.

ecstatic shouldn't attempt to gzip anything on the fly, but rather if the client accepts compressed resources and a file.ext.gz exists then serve that, if not serve the file.ext if it exists.

Id be happy to work on a pull request if you agree with having this feature.

send length of file

example with plain http server

i wanna copypaste example code using just require('http') but its not in the readme and i am lazy

relative links are broken

If you visit a folder with an index file without putting a trailing '/', relative links don't work correctly. eg, if you visit the index page at "www.yoursite.com/folder" and click on a relative link to "otherFolder/random.html", the path will be resolved as "www.yoursite.com/otherFolder/random.html", instead of the appropriate "www.yoursite.com/folder/otherFolder/random.html". I suppose the fix to this is to redirect the browser to the same folder with a trailing '/'.

when the file extension is `.constructor`, there's a header `content-type: function Object() { [native code] }`

Basically, we need to do a .hasOwnProperty check against mime.

Cache-Control

Implement the Cache-Control header. It's a necessity for any static file server: https://github.com/cloudhead/node-static/blob/master/lib/node-static.js#L39

v0.2.0 roadmap

COMPLETE:

• Refactor of overall code structure (cps, less middlewares, generalized custom error page behavior)
• Includes fixes from v0.1.x branch (writeHead, path.join, etc.)
• Fix mime typer

TODO:

• Add test coverage for union
• Add test coverage for flatiron/director
• Add test coverage for flatiron/broadway
• Add test coverage for 304 caching
• Add test coverage for showing empty directory
• Add 'equip' wrapper.
• Write documentation for all new parts
• Make the tests pass.
• Close issues.

FUTURE:

• Rewrite tests to use vows
• Add test coverage for mime typer
• Investigate the null byte issue

Add a handler for director-based routing

something like,

ecstatic.direct(options) {

    ecstatic(options)(this.req, this.res, nextShim);

}

Status code not set to 304

I have been having a problem in that the http response status code is 200 rather than 304 for files which have not changed. It works for me if I make the following change in status-handler.js

exports['304'] = function (res, next) {
  res.writeHead(304, res.headers);
  res.end();
};

I don't really understand why and it could potentially need to be similarly changed in several other places in that file, so would rather see if anyone understands it before I submit a pull request.

Cheers,
Colin

Always serve a fresh file

n/m, it was a dropbox issue. :(

gzip issues

gzip is not in the opt parser. When I add it and try to use that feature it is buggy. What is the status of gzip support?

Arguments to path.resolve must be strings

Hey Josh,

I recently updated my local version of node to v0.10.10 and ran into a strange path.resolve error when trying to run ecstatic based on the documentation provided.

Below is the full error stack.

$ node -v
v0.10.10

$ node app.js 

path.js:313
        throw new TypeError('Arguments to path.resolve must be strings');
              ^
TypeError: Arguments to path.resolve must be strings
    at Object.exports.resolve (path.js:313:15)
    at module.exports (/Users/cole/Public/github/rgb/node_modules/ecstatic/lib/ecstatic.js:14:29)
    at Object.<anonymous> (/Users/cole/Public/github/rgb/app.js:16:5)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:901:3

The path.resolve api does not look like it has changed so I am not sure why updating node would have made a difference here.

I was able to fix this issue by simply passing in a string instead of an object for the directory in the ecstatic options. I could totally be missing something obvious here but I thought it would be best to make you aware of what I encountered. Let me know if you have any questions or if I can help in any way.

Broken example:

app.use(flatiron.plugins.http, {
  before: [
    ecstatic({ root: __dirname + '/public/' })
  ]
});

Working example:

app.use(flatiron.plugins.http, {
  before: [
    ecstatic(__dirname + '/public/' )
  ]
});

"handleError" does not work with a 404.html

The handleError option does not appear to be working when you have a 404.html file in your root dir. https://github.com/jesusabdullah/node-ecstatic#fall-through

Given the following simple app and a 404.html file in the public, I cannot get to the /version route.

var ecstatic = require('ecstatic');
var flatiron = require('flatiron');
var app = flatiron.app;
var port = 3000;

app.use(flatiron.plugins.http, {
  before: [
    ecstatic({
      root: __dirname + '/public',
      handleError: false
    })
  ],
  after: []
});

app.router.get('/version', function () {
  this.res.writeHead(200, { 'Content-Type': 'text/plain' });
  this.res.end('flatiron ' + flatiron.version);
});

app.start(port);
console.log('Flatiron running on ' + port);

I would expect that even though a 404.html file exists it would fall through to the router.

In fact it looks like handleError is a total no-op and doesn't appear anywhere in the codebase. https://github.com/jesusabdullah/node-ecstatic/search?q=handleError&ref=cmdform

option to set response headers, specially for CORS

I'm developing locally and need multiple servers running on different ports, so XHR doesn't work (different port is also blocked by same-origin policy).

I want to simply add Access-Control-Allow-Origin: * to the response header but other users might have different needs so I'm thinking on a new option to set the custom headers:

var opts = {
  root: __dirname + '/public',
  header: {
    'Access-Control-Allow-Origin': '*',
    'X-Foo': 'bar'
  }
};

If you agree I can implement this feature and ask for a pull request next week.

example directory listings are broken

The union example now gives:

Not Found.

and the express example says

Cannot GET /

the core.js example works.

This bug seems to relate to the new logic at lib/ecstatic.js line 40 so that showDir only ever fires when next isn't a function.

req.showdir

In order to ensure that an auto-generated directory view is shown instead of a custom 404.html page (this only happens if 404.html exists), a property now gets a boolean property called 'showdir' attached to it.

This is almost definitely a bad idea, but hard to fix without a code refactor.

URIError: URI malformed

https://github.com/jesusabdullah/node-ecstatic/blob/master/lib/ecstatic.js#L32

Will throw an error if the path given is not properly encoded, for example, when the path is /%

When this happens, the request will hang.

xss issues

The new directory listing code from nodejitsu's static server has some xss flaws since req.url comes directly from the user and hasn't been filtered at all. It should go through a combination of encodeURI() and ent.encode() before being rendered to the page.

better directory view, in valid html

Right now it doesn't even have body tags.

Use HTML5 doctype?

Should we use HTML5 doctype?
I'm thinking of modifying showdir.js:render() to something like this:

- var html = '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"\
-   "http://www.w3.org/TR/html4/loose.dtd">\
+ var html = '<!doctype html>\
+   <meta charset="utf-8">\

[doc] readme should say that default cache is `3600`

Thanks for working on this project, was good meeting you the other day at the falafel thing :)

Not working on Windows

I am having to work on a Windows XP machine today, and node-ecstatic does not appear to work on WIndows.