This project is read-only.


Wrong EncodingName in NullCompressor



I found a bug which took me a long long time to find. It seems that the NullCompressor set the EncodingName property to "utf-8". This in turn results in that the Content-Encoding response header is set to "utf-8" for clients that does not want gzip.

This is wrong.The correct encoding when no compression is applied should be: "identity".

"utf-8" seems to be working in most browsers but I found that on some phones and only on the swedish cell carrier "Telia" files served with combress did not work. After alot of poking I found that the gateway of "Telia" responded with that UTF-8 was not a valid encoding and did not server the file. This was later traced to combres.

Could you please fix this?
Closed Aug 31, 2012 at 6:02 PM by buunguyen
Fixed in 359a404e315c


buunguyen wrote Jun 2, 2012 at 8:08 PM

Hi, can you point to some references showing why "identity" is correct and "utf-8" isn't?

reineo wrote Jul 5, 2012 at 1:39 PM

From the RFC (
"If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client... "
"The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type..."
"If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable..."

Content-Encoding shuld only be set when compressing the response (i.e gzip).
If the client (or the load balancer in our case), doesn't provide Accept-Encoding, use the above behavior. combined with specifying the encoding in the Content-Type header.
Accept-Encoding : [blank]
Content-Type: text/css; charset=UTF-8
Content-Encoding: [blank] (or identity)

buunguyen wrote Aug 29, 2012 at 7:58 PM

I've checked the code and tested again, NullCompressor doesn't set content-encoding at all. So not sure why you got that content-encoding=utf-8. The current behavior is exactly as you describe: Content-Encoding shuld only be set when compressing the response (i.e gzip).

reineo wrote Aug 30, 2012 at 7:27 AM

Current Combres code base:

public string EncodingName
get { return "utf-8"; }

RequestRpocessor.cs => SendOutputToClient
response.AppendHeader("Content-Encoding", Compressor.EncodingName);

Our current workaround looks like this:

public string EncodingName
get { return null; }

RequestRpocessor.cs => SendOutputToClient
if (Compressor.EncodingName == null)
response.ContentType += "; charset=utf-8";
response.AppendHeader("Content-Encoding", Compressor.EncodingName);

buunguyen wrote Aug 30, 2012 at 5:37 PM

This is the code of NullCompressor from the trunk:

I'm not sure which code version you're looking at, but it must be obsolete.

reineo wrote Aug 31, 2012 at 8:32 AM

The code comes from "Source Code -> Branch -> Latest version". I've just realized the link doesn't point to the latest code base. It seems to be the last stable code according to CodePlex (v That is also the binary version we've been using. I now realize we must use NuGet to get the latest version, including the fix for NullCompressor.
So the fix for us is to accuire Combres through NuGet instead of CodePlex :)

buunguyen wrote Aug 31, 2012 at 5:48 PM

I see what you mean now. Yes, the "latest" points to "stable", not really "latest". Also, all the download binaries in CodePlex is obsolete; guess I should remove all of them. So either use NuGet or build from the real latest (359a404e315c).