Forum Discussion
Krzysztof_Kozlo
Nimbostratus
NimbostratusCompress::enable vs browser workarounds
As some of you may know, IE6 fails to handle the following header on compressed content:
Content-Disposition: inline; filename=xxxxxx.xxx
this results in dynamically-generated reports failing to open in the properly associated application, since IE assumes the filename to be the tail end of the URL that generated the report, rather than the one specified in the Content-Disposition header.
So, questions arise:
- why is this not handled as part of 'compress browser workarounds enable'? (at least as of v9.1.1 -- is it handled in later versions?)
- has anyone written an iRule to deal with it? (I'm quite confident I can handle the task but why reinvent the wheel...)
Regards,
Chris Kozlowski
Morgan Stanley Enterprise Infrastructure
2 Replies
Krzysztof_KozloAs long as I'm just talking to myself here, I'll answer my own question:
rule no_compress_inline_ie {
when HTTP_REQUEST {
if { [HTTP::header Content-Disposition] contains "inline" } {
if { [HTTP::header User-Agent] contains "MSIE" } {
COMPRESS::disable
}
}
}
I've got a case open to see why "Browser Workarounds" don't include this fix, but so far no one's answered that either.
Chris Kozlowski
Morgan Stanley Enterprise Infrastructure
hoolioCirrostratus
Hi Chris,
I don't have any experience with IE's (or BIG-IP's) handling of compression. I talked with someone in support though and asked if they could take a look at your case. If you don't hear anything today on the case, you could try calling support.
And thanks for posting your workaround...
Aaron
