Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(plugin): plugin to serve static files #1753

Merged
merged 3 commits into from Mar 4, 2019

Conversation

rajatkumar
Copy link
Member

Pre-Submission Checklist

  • Opened an issue discussing these changes before opening the PR
  • Ran the linter and tests via make prepush
  • Included comprehensive and convincing tests for changes

Issues

Closes:

Summarize the issues that discussed these changes

Changes

Added the serveStaticFiles plugin and set of tests. Also updates the docs to reflect this new plugin and its API.

What does this PR do?
Adds another plugin to serve static files. This plugin uses send under hood, which is the same library that expressjs relies on. This should resolve most of the other issues developers have seen with restify's static plugin.

I decided to keep the existing plugin along with this one so that we are not breaking any existing usage of the static plugin in the ecosystem.

@rajatkumar rajatkumar changed the title Feat static file serve plugin feat(plugin): plugin to serve static files Feb 23, 2019

// when `send` encounters any `error`, we have the opportunity
// to handle the errors here
stream.on('error', function handleError(err) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about:

        stream.on('error', function handleError(err) {
            // When file does not exist
            if (err.statusCode === 404) {
                return next(new ResourceNotFoundError(requestedFullPath));
            } 
            // or action is forbidden (like requesting a directory)
            return next(new NotAuthorizedError(requestedFullPath));
        });

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will it be always NotAuthorizedError ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to put down explicit cases and hence the if/else structure. I foresee we might have other cases(which we find later on as people start using this plugin) where we want to send explicit errors.

If it is fine, I would like to keep the current structure.

@@ -0,0 +1,131 @@
'use strict';
var assert = require('assert-plus');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this plugin is for new versions only, maybe we can use let/const here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not want to tackle the eslint rule that disables usage of es6 constructs in code as part of this PR. (Refer: https://github.com/restify/node-restify/blob/master/.eslintrc.js#L12). Let's keep that for a future PR where we might convert vars -> consts/let in the codebase.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

* @public
* @function serveStaticFiles
* @param {String} directory - the directory to serve files from
* @param {Object} opts - an options object, which is optional
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth calling this out as an options object meant explicitly for send? I think we do something similar with other plugins like mime.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The options object is not explicitly for send, I added another functionality (similar to express) that allows us to set custom headers by passing a function under options.setHeaders. eg.

setHeaders: function setCustomHeaders(response, requestedPath, stat) {
              response.setHeader('restify-plugin-x', 'awesome');
          }
 })

Also, we explicitly override options.root before passing to send. So the other options might be similar to what send needs but they are not explicitly for send.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, makes sense. This might be paranoia but if it's not too expensive, you could think about making a new copy of opts when we call send but with only send specific options. It's nice to be able to separate internal opts from send opts. At the minimum - worth calling out in the jsdocs what's used by us vs used by send.

@rajatkumar rajatkumar merged commit a67b25f into master Mar 4, 2019
@sean3z sean3z deleted the feat_static_file_serve_plugin branch September 29, 2019 16:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants