Fix issue with sendOptions.maxAge being overwritten

[ceecko]

This fix resolves issue with sendOptions.maxAge being overwritten when 404 is returned.
The following scenario resets the maxAge property:

1. Load static file which exists (maxAge respects configured sendOptions)
2. Load static file which does not exist (maxAge is set to 0)
3. Load static file which exists (maxAge is set still to 0 and MAX_AGE is used instead)

[XhmikosR]

@ceecko: if you add a test for this, we can merge it.

[ceecko]

@XhmikosR I have added tests and a new option maxAgeNonHashed which specifies maxAge for non-hashed assets to add more flexibility.

[XhmikosR]

I'd still like to have a test for max-age=0, which is the default.

[ceecko]

The tests on lines 97 and 136 already check max-age=0
This test suite is meant to check custom max-age for non-hashed assets

[XhmikosR]

Also, please fetch upstream and rebase. :)

[XhmikosR]

That's a merge not a rebase BTW. So it's unmergeable.

[XhmikosR]

git rebase -i upstream/master and fix your commits please.

[ceecko]

Yeah, sorry. Messed up a bit.
Now it should be fine.

[XhmikosR]

Thanks, I'm gonna have a look tomorrow.

[XhmikosR]

Can't we move these 2 into setOptions?

[ceecko]

Yep, makes sense

[XhmikosR]

I still feel like the following assignments aren't all needed.

We just have one options Object. Can't you put the new options there and just base your logic on maxAge?

[ceecko]

If there was only one options object, the logic in serve would have to change maxAge for non-hashed assets and after calling send reset maxAge back to original value which may be confusing and introduces unnecessary overhead with every call.

The reason for this pull request is to resolve issues with a single options object's maxAge being overwritten when a non-hashed asset is requested. Such call resets maxAge to 0 and all subsequent requests started to use MAX_AGE.