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

Check extensions on a directory before redirecting #107

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

cag
Copy link

@cag cag commented Apr 5, 2016

I decided to change the behavior on the send module in a project and discovered that I really wanted sendFile to send things.json for a GET request to things when stuff like things/1.json exist.

index.js Outdated
@@ -612,14 +612,16 @@ SendStream.prototype.sendFile = function sendFile(path) {

debug('stat "%s"', path);
fs.stat(path, function onstat(err, stat) {
if (err && err.code === 'ENOENT'
var isDirectory = stat && stat.isDirectory();
Copy link
Member

Choose a reason for hiding this comment

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

Stat will be undefined if there's an err.

Copy link
Author

Choose a reason for hiding this comment

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

That's why I prefixed it with stat &&. That's idiomatic, right?

@dougwilson
Copy link
Contributor

Hi! Thanks for your pull request, but it does not include any tests for the change you made, does not include documentation, and even breaks existing tests.

According to the tests this change broke, this change is actually breaking a feature of this module. Can you explain more what you change is doing, how it compares to the current functionality, and why it breaking our existing tests?

@cag
Copy link
Author

cag commented Apr 6, 2016

I changed the tests to reflect what I mean and fixed an issue.

@cag
Copy link
Author

cag commented Apr 11, 2016

According to the CI, this is only failing on node 0.8 now due to some package.json parsing thing. I've written a test, modified a test, and made sure all the existing tests pass. Could you please consider this PR for the next release?

@dougwilson
Copy link
Contributor

Hi @cag! It looks like you never actually answered all my questions in #107 (comment) . So, since I didn't get an answer, I can only make assumptions on what you are trying to do based on the code changes.

This is a breaking change and will have to wait for the next major version at some point. Currently directories are preferred over extension-less files, and changing this will not be a backwards-compatible change.

@dougwilson dougwilson added the pr label Apr 11, 2016
@dougwilson dougwilson self-assigned this Apr 11, 2016
@cag
Copy link
Author

cag commented Apr 11, 2016

Sorry, I was a bit headstrong and forgot to elaborate. You're right that this change may potentially break distributions that depend on this package, but my feeling is that the behavior change is the natural one.

I changed the behavior of the extensions option so that for this:

resource.json
resource/
    item1.json
    item2.json

with extensions=['json'], resource, resource/item1, and resource/item2 returns the JSON files. I did it because OS's don't usually allow files to share names with directories, and because I wanted to stand a mock back-end up with serveStatic and connect.

Currently, send sends a redirect for resource with extensions set where a file exists with that extension. This change checks through the file extensions first before sending the redirect.

I changed the description for one of your tests to reflect the above, but I have fixed my code changes so that they don't break your tests.

@dougwilson
Copy link
Contributor

Thanks, @cag! Yes, this change makes sense. The reason I bring up the it being a breaking change is because this conflict was known about when the extensions feature was added and it was decided at the time to prefer the directory over looking for a file with the given extension. Because of this history, I see your PR here as a proposal to change that behavior, not a bug fix. I hope that makes sense.

@cag
Copy link
Author

cag commented Apr 11, 2016

That's totally fine. I didn't think of it as a bugfix. This is just the scenario I personally ran into in the wild.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants