Need some advice: Changing Meteor's behavior of not ever returning 404


#1

Please Note: I know how to code the solution using webapp connect handlers, I’m looking for problems my solution might present.

Background
Meteor returns the the conglomerated html page it builds from your client/*.html files for requests for a file it can’t find. It never returns a 404 response.

So let’s say your project contains only these three files:

  • client/myapp.html
  • client/sometemplate.html
  • public/diagram.png

A request to localhost:3000/diagram.png will return the image. A request to any other url will return Meteor’s built html file with the contents of your two html pages plus a bunch of scripts that it adds. That includes urls like:

  • localhost:3000/mystuff/hello.md
  • localhost:3000/art/bird.png

It will never return a 404.

Now it seems obvious that this behavior is intended so that we can create meteor projects without ever explicitly creating a file called index.html or the like. However, it’s been causing me some grief with a package I’m writing that requires much (Edit: all) of the front end content to be served from sub-folders of the public folder. Bugs in file paths etc return some big html file instead of the usual and expected 404 response.

My Solution
If someone installs my package, I’d like to turn off the above behavior for any request that isn’t in the root of the project. Therefore the following requests will return the normal meteor html file:

  • localhost:3000
  • localhost:3000/index.html
  • localhost:3000/myapp.html

However, any request that contains a non-root folder would either return the file or a 404 if it doesn’t exist. This would apply to URLs like:

  • localhost:3000/art/spaghetti.jpg
  • localhost:3000/webapp/somethingsomething.js

Again, I know how to code it - it’s already working for me. I’m just not sure if the above behavior would be undesirable in some scenario that I can’t think off.

TIA to anyone who can advise of a such a scenario.


#2

JavaScript gets bundled so that might be an exception but for the rest there is no issue. In general you let your router handle this.


#3

Yeah my package relies on non-bundled resources served from the public folder so that’s fine.

Apps built with my package would also never use Blaze, Flow-router or Iron-Router.

Thanks for your response.


#4

Did you ever figure out a solution for this? I am building a single page app with angular so I have no need of any other router such as flow router or iron router.