Crashes

[microsoft]

Crashes

[bangbingsyb]

@EatonZ I like this idea :) Will try to implement it. Thanks for the suggestion again.

[bangbingsyb]

@EatonZ The new release (v1.0.3219) has been published and is available through the same download link. The issue has been fixed in the new release - both iiszlib and iisbrotli auto-adjust the out-of-bound compression level to the maximum allowed value and produce a warning to event log (but only emit a single warning event per worker process life time).

[shirhatti]

@EatonZ 10 is not a valid compression level for the iiszlib.dll provider.
See the docs at https://docs.microsoft.com/en-us/iis/extensions/iis-compression/using-iis-compression#compression-level

cc @bangbingsyb

[EatonZ]

My fault for missing that - the max was 10 in the built-in providers so I assumed that was the case here.
I feel as though you could maybe change this crash behavior to instead log a warning and internally use the max value if the value in the settings is larger (so it won't crash).

[bangbingsyb]

@EatonZ : thanks for raising the issue. Here is my personal thought on this. A potential improvement could be the compression scheme checks the range and returns an error to IIS once the configured level is out of the allowed range. In this case, IIS might return 500 to the client. For developers or admins this might be relatively easy to troubleshoot using IIS failed request tracing (FREB log).

Note that a compression scheme has extremely limited control over the response, since it doesn't directly access the headers, status code, and only accesses the contents buffer by buffer. So to really raise a meaningful warning (e.g. a event) it might require support from IIS static/dynamic compression modules. I will look into the compression modules to see if we have already had such mechanism either through event log or through FREB log.

I personally think modifying the out-of-bound compression level to a valid one on behalf of the user is probably a bit misleading, and fail the request in a graceful way with easy access diagnosis info might be the best approach.

[EatonZ]

@bangbingsyb Can the module write to the Event Viewer? A simple message there like "Compression level out of bounds." would be helpful and shouldn't involve any big IIS changes. I get messages from ASP.NET that say "A potentially dangerous Request.Path value was detected from the client" in the Event Viewer, so this seems like a reasonable thing to add.

[bangbingsyb]

Resolved by #17

[EatonZ]

@bangbingsyb Thank you for a great-looking fix!
When will updated installers be available?

[bangbingsyb]

@EatonZ Will work on the installer change this week, and we will have a new release hopefully next week.

[EatonZ]

@bangbingsyb Let me know when the new installer is available.

[bangbingsyb]

@EatonZ Sure. Sorry for the delay. I completed the installer update last week in our internal repository, and basically all necessary code changes for the new release have been in place. I need to make some minor fix to our build definition before the release. I'm having a tight schedule last and this week for other tasks. Will keep you updated once the installer is ready.

[EatonZ]

@bangbingsyb Is the new version available yet?

[EatonZ]

@bangbingsyb Checking in again ^

[EatonZ]

@bangbingsyb @shirhatti Did you decide against publishing an update for this?

[bangbingsyb]

@EatonZ sorry for the long delay. I was switched out to other tasks and we also had infrastructure changes during the period. Now I've moved all the installer pieces to the same repository, and will work on a new release soon.

[EatonZ]

@bangbingsyb Great - thanks!