The mobileOK Basic spec is silent about content-encoding.

The mobileOK Checker does not support compressed content at all, i.e.:
- it does not send an Accept-Encoding HTTP header field in HTTP requests
- it does not parse any received Content-Encoding HTTP header field
- it does attempt to parse compressed content as HTML content, and obviously stops with an error right after having read the first few bytes.

In short, when the page under test uses compression, the report of the mobileOK Checker will look like "The document is not an HTML document and is not valid UTF-8" (also see Bug 10947). That is highly misleading.

The HTTP RFC advises servers against using compression when the request does not contain an Accept-Encoding HTTP header field, but it's a SHOULD, not a MUST:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3

At the very least, the mobileOK Checker should add a warning that it cannot process compressed content. It should also warn that it is not a good practice to use compression when the device has not been explicit about compression support.

Since using compressed content is actually a "good thing", the mobileOK Checker should probably also support common compression algorithms (deflate, gzip).

(Side note to keep in mind: PAGE_SIZE_LIMIT applies to decompressed content)