Does */* in an HTTP Accepts-Encoding Header Mean Gzip is Supported?

Question

I'm trying to serve up some JS and CSS files from Amazon CloudFront using Gzip. Following their instructions, it seems that I'm supposed to determine if the client supports Gzip when rendering my page, and if so, I append .gz to the file URL.

The problem is that when I inspect browser requests, they do seem to add Accepts-Encoding:gzip (or deflate) headers to requests for JS or CSS files, but not for the HTML file. The HTML request is where I need to read the header. The JS or CSS requests are going to CloudFront, not my server.

So, if I see / in the Accept-Encoding for the HTML request, is it safe to assume the clients supports gzip?

Answer 1

According to RFC 2616, section 14.1, The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types.....

Read more about this here http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

In short Accept-Encoding: */* means all media types are accepted and Accept-Encoding: gzip means gzip compression is accepted.

Answer 2

Not exactly. While */* means the client claims "I'll accept anything", I could invent a new encoding this afternoon that nothing on the planet will accept, and watch as browsers that accept "anything" fail to handle it. (For a (content-type) Accept header, / makes more sense, because browsers can always just save the file).

That said, support for gzip encoding is extremely widespread, so it is safe to assume that any client claiming to accept it (or accept "anything") will support it.