4.1.0.0

Enhancements

#169 Automatically Determine ContentType Based On File Extension

When sending a response that is a static asset from a public folder, the content-type header will now be set based on the file extension. If there is no extension or no matching content type is found for the extension, then the default will be used.

Defects

#157 Mono lacks support for ExtendedProtectionSelector

Removed the ExtendedProtectiongSelector property from the API.

I know this violates semver here. Because I am removing part of the API and therefore introducing a breaking change, I should do a major version change (from 4 to 5). But I'm not going to do that - opting instead to go to version 4.1 - for two reasons.

1. This API feature was actually making the library unusable for some people. And to the best of my knowledge, this isn't a feature anyone is using. I honestly don't get much feedback from my users base unless there is a problem, so it might just be a matter of not enough of the right kind of feedback, but if you really want to use this feature of the API, just stay on version 4.0.

2. Version 5 is already underway, and it not only includes many, many other breaking changes, it also provides a spectacularly better way of managing these kinds of API/dependency feature implementation thingys (i.e., exposing features of the underlying http implementation to the user). In fact, changes in version 5 will make it possible to provide future minor versions (e.g. 5.1, 5.2, etc.) that don't rely on the HttpListener class at all. I may never do this, but at least if I don't it won't be because my library is too tightly coupled to the existing HttpListener implementation.

#175 Memory Leak in Route Caching

I implemented route caching in a previous release with the intention of speeding things up, then later realized my hasty implementation could cause a memory leak. This doesn't change the API at all, and I may enable the feature at some future point with a better implementation (and a feature toggle), but for now I just removed the offending code.

#177 Managing HttpListenerException On Closed Connections

If the client closed the connection before the server could send the response, then when the server finally started sending the response an error was thrown, and the block that caught the exception was try to send an Internal Server Error (500) response, which would cause another exception to be thrown, and that would cause the server to crash.

Fixed it so that the exceptions get properly handled, and the response get closed so that no other route can try to write to the closed output stream.