We are running WebForms and MVC apps side by side (in one project) and have RadCompression enablePostbackCompression enabled. This causes a problem in our MVC app, whenever a request returns 500 status code.
The easiest way to reproduce this is to enable postback compression, decorate an action with a HandleError attribute (which returns 500 in case of an unhandled exception), turn custom errors on and throw an exception inside the action. The expected result would be to be redirected to the error page. Instead, we get an encoding error because RadCompression module appends "gzip" to Content-encoding header without checking whether it was already appended, resulting in "Content-encoding: gzip,gzip".
What are my options besides turning off postback compression altogether? Ideally, I'd want to use RadCompressionSettingsAttribute to disable compression for a given action or controller but that hasn't worked. Any thoughts?
The easiest way to reproduce this is to enable postback compression, decorate an action with a HandleError attribute (which returns 500 in case of an unhandled exception), turn custom errors on and throw an exception inside the action. The expected result would be to be redirected to the error page. Instead, we get an encoding error because RadCompression module appends "gzip" to Content-encoding header without checking whether it was already appended, resulting in "Content-encoding: gzip,gzip".
What are my options besides turning off postback compression altogether? Ideally, I'd want to use RadCompressionSettingsAttribute to disable compression for a given action or controller but that hasn't worked. Any thoughts?
3 Answers, 1 is accepted
0
Hello Marat,
As you probably know execution life cycle of a MVC application differs from that of a WebForms app. Note that RadCompression is a HTTP module and its functionality depends pretty much on Request, Response and endpoint Handler objects (especially the postback compression). Since those differ between MVC and WebForms environment, I am afraid that the postback compression was not designed to work in MVC projects. Although it may work in some MVC scenarios, RadCompression is only supported when used in ASP.NET WebForms apps.
I hope this helps.
Kind regards,
Martin
the Telerik team
As you probably know execution life cycle of a MVC application differs from that of a WebForms app. Note that RadCompression is a HTTP module and its functionality depends pretty much on Request, Response and endpoint Handler objects (especially the postback compression). Since those differ between MVC and WebForms environment, I am afraid that the postback compression was not designed to work in MVC projects. Although it may work in some MVC scenarios, RadCompression is only supported when used in ASP.NET WebForms apps.
I hope this helps.
Kind regards,
Martin
the Telerik team
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now.
0
Marat
Top achievements
Rank 1
Rank 1
answered on 01 Mar 2013, 08:25 PM
Martin,
thank you for your reply.
I understand your point and just want to point one thing out - the way "ShouldExplicitlyAddContentEncoding" is implemented is not optimal. In cases of 500 response codes it does not check whether the gzip content encoding has already been applied. While I understand that execution lifecycle is different between MVC and WebForm apps, I think it's also important to make sure that modules do not introduce side effects, especially if Microsoft allows us to run the two frameworks side by side.
Btw, if it were up to me, I'd just report this as a bug, since the solution to this problem seems very straightforward (just check whether "gzip" was already applied).
thank you for your reply.
I understand your point and just want to point one thing out - the way "ShouldExplicitlyAddContentEncoding" is implemented is not optimal. In cases of 500 response codes it does not check whether the gzip content encoding has already been applied. While I understand that execution lifecycle is different between MVC and WebForm apps, I think it's also important to make sure that modules do not introduce side effects, especially if Microsoft allows us to run the two frameworks side by side.
Btw, if it were up to me, I'd just report this as a bug, since the solution to this problem seems very straightforward (just check whether "gzip" was already applied).
0
Hello Marat,
Note that by the time RadCompression was designed and implemented, the Microsoft MVC framework was not released yet. Because of the that RadCompression doesn't support MVC applications by design.
It is true however, that its code can be reviewed and refactored so that its postback compression works in MVC as well. The problem is that currently RadCompression supports many different scenarios in different frameworks and IIS versions. Refactoring its code so that no new issues or breaking changes are implemented should be made very carefully. I can assure you that although from your point of view the fix looks very straightforward, the actual implementation could be quite different so that RadCompression continues to work in all scenarios and environments it currently supports.
Based on the above and for the time being, I would suggest that you override RadCompression on your side (the ShouldExplicitlyAddContentEncoding method) so that it works as expected in your custom application. I am also logging a feature request about your query and based on our clients demand and community votes, our developers may consider implementing this feature in one of our future releases.
All the best,
Martin
the Telerik team
Note that by the time RadCompression was designed and implemented, the Microsoft MVC framework was not released yet. Because of the that RadCompression doesn't support MVC applications by design.
It is true however, that its code can be reviewed and refactored so that its postback compression works in MVC as well. The problem is that currently RadCompression supports many different scenarios in different frameworks and IIS versions. Refactoring its code so that no new issues or breaking changes are implemented should be made very carefully. I can assure you that although from your point of view the fix looks very straightforward, the actual implementation could be quite different so that RadCompression continues to work in all scenarios and environments it currently supports.
Based on the above and for the time being, I would suggest that you override RadCompression on your side (the ShouldExplicitlyAddContentEncoding method) so that it works as expected in your custom application. I am also logging a feature request about your query and based on our clients demand and community votes, our developers may consider implementing this feature in one of our future releases.
All the best,
Martin
the Telerik team
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now.