CSS 11501, compression, file extensions and content-types

[Jason Lingohr]

Hi all,

I've discovered something odd in my configuration, whereby I'm not seeing compression being done when I think it should be.

• Version: 8.20
• Methods: SSL termination/acceleration, compressing on SSL
• Hardware SSL module installed
  

Basically, I'm asking the question: does both the Content-Type and file extension have to match before the CSS will compress?  What's the boolean logic on the matching?

What I'm seeing is .do file extensions, but the content type is either text/html, or text/xml, and response headers not showing any gzip/deflate happening.

Not sure if this is a bug, or related, but I am seeing charset=UTF-8 being passed with the Content-Type header:

Content-Type: text/html; charset=UTF-8

A way to modify matched extensions for obviously compressible content would be great to know

Thanks for any info

[Gilles Dufour]

Do you have the CSS11501 or CSS11501S or CSS11501S-C ?

The first one does not do compression.

http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/css11500series/v8.20/configuration/ssl/guide/Compress.html

The CSS supports compression on specific file extensions and content  types. The supported file extensions are:

•.asp

•.aspx

•.css

•.htm

•.html

•.jhtml

•.js

•.jsp

•.php

•.shtml

The supported content types are:

•application/x-javascript

•text/plain

•text/html

•text/css

It's a logical AND .. so both needs to match.

Gilles.

[Jason Lingohr]

This is the model I have:

Unique Device Identifier:

NAME: "chassis   ",  DESCR: "Cisco 11501 Content Services Switch SSL Compression HD AC"
PID: CSS11501S-C-K9    ,  VID: xxx,  SN: xxx

So yeah, it's the right one for hardware compression.

And damn... that's really silly that it's an AND.  It's quite normal to now rely on Content-Type and not file extension -- how archiac.

I've not found any way to amend the extensions either; except some vague mention back in 2007 of using EQL's (I think it was called)?

[Jason Lingohr]

Any thoughts on this?

It seems a bit silly that we can't amend the file extensions to be compressed (as I believe this is my issue).  Content-Type that is coming back is perfectly-compressible text/html, it's just that the file extension is .do.