1.x #435

wants to merge 77 commits into


None yet
4 participants

cainus commented Dec 12, 2011

Hey all...

I changed the static middleware to ignore ENAMETOOLONG like it does with ENOENT, because obviously it's also a static file "miss", and the request should (IMHO) continue on to subsequent middleware (where it could actually be a valid api url). I added the relevant unit test as well.

Feel free to integrate this. Thanks for the great lib either way.

tj and others added some commits Jul 19, 2011

Added response "header" event allowing augmentation
this will be used in the session middleware, and could
be used elsewhere. Ideally Node would provide a hook for us...
Changed: dispatcher errors after header is sent destroy the sock
for example:

    .use(function(req, res){
      res.setHeader(Content-Type, text/plain);
Changed: ignore error handling middleware when header is sent
until we come up with a better solution
either this or every error-handling middleware
needs to check res.headerSent
Added `staticCache()` middleware
this cache layer is ~29% faster than node-static
plus we have more features :) so there is very
little reason to it now
Changed `limit()`: respond with 413 when content-length exceeds the l…

we could do this with chunked as well
although you would be stuck waiting for a
potentially _massive_ body

tj and others added some commits Oct 12, 2011

Removed socket error listener in static(). Closes #389
you will have to handle this yourself if you
are interested.
Removed staticCache tests for now
nested assert.responses fail hard on node 0.5.x

this is not really a "bug" in expresso since
it was never designed to work with nested
responses, but I will fix this asap
blank test in staticCache.test.js to trick expresso
otherwise tests will hang since it waits for exports
Changed the static middleware to ignore ENAMETOOLONG errors and inste…
…ad allow subsequent middleware / handlers to handle to handle the problem. The current connect default seems to be to 404 on this, which is probably fine, because the file can't exist if the name is too long. Another possible default would be to return 414 (uri too long), but it's a mistake to do that in this middleware, because maximum URI length probably exceeds maximum filename length, so it might be a valid length

for subsequent middleware / handlers.

Relevant unit test was added.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment