When a response gets compressed earlier in the pipeline then i18n has been corrupting the response (generally resulting in the ERR_CONTENT_DECODING_FAILED error seen on Chrome). I am pretty sure that this is because the compressed data coming into the stream is copied to the MemoryStream and then encoded with the UTF-8 encoding, you can't do that with compressed data, which is a binary stream. When the encoded string is then rewritten to the output stream it is no longer a valid copy of the original binary compressed bytes and the response stream is no longer valid gzip content, so the client cannot decompress it.
That being the case, the i18n module needs to detect when the incoming data is compressed and do nothing to it. I have added two checks to prevent this corruption - first, I have found that although the Response.ContentEncoding will be set to UTF-8, if the response is compressed, then then Content-Encoding header in the Response will be set to gzip, I'm checking for that in LocalizingModule and do not install the filter if that is true. Secondly I am checking for the two bytes at the beginning of the input stream that identify the content as gzip compressed (1F 8B), if they are found I set a private flag in ResponseFilter and then pass the content through unchanged when the flag is set.
This does not allow the i18n module to localize content that has already been compressed but I don't think that needs to be a goal of the module - if someone wants to localize static files then they can turn off static file compression, or they must put the content into files/handlers that are dynamic. The key thing is to have the module reliably do nothing when the incoming stream is already compressed - if anyone else has examples of content types/scenarios where errors still occur please add them to this issue and I'll try to add more tests to exclude the compressed content from being touched by the module.
Prevent empty responses to requests for WebResource.axd - this is a legacy tech, but it's relatively simple to have i18n play nicely so I added the fix. The fix is discussed in various forums and involves using reflection. I would suggest that WebResource.axd and ScriptResource.axd can be added to the default list of excluded URLs because I don't think it would be a good idea to localize either of them anyway, but this fix makes sure that i18n doesn't break WebResource.axd if someone does leave it being localized.
I have not done extensive testing with these changes in an MVC environment, but they are working well in development in a fairly large web application that does use lots of content types.
These commits deal with two known issues:
This does not allow the i18n module to localize content that has already been compressed but I don't think that needs to be a goal of the module - if someone wants to localize static files then they can turn off static file compression, or they must put the content into files/handlers that are dynamic. The key thing is to have the module reliably do nothing when the incoming stream is already compressed - if anyone else has examples of content types/scenarios where errors still occur please add them to this issue and I'll try to add more tests to exclude the compressed content from being touched by the module.
I have not done extensive testing with these changes in an MVC environment, but they are working well in development in a fairly large web application that does use lots of content types.