341944 - Regression: Minefield no longer accepts "Content-Encoding: identity" HTTP header

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Brion Vibber]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060618 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060618 Minefield/3.0a1

According to HTTP 1.1 spec, the default value for 'Content-Encoding' is 'identity', which specifies no compression.

While this works in previous versions of Firefox including 1.5.0.4, in Minefield explicitly setting this header causes the file to be rejected, displaying an error message.


Reproducible: Always

Steps to Reproduce:
1. Find a page that sends 'Content-Encoding: identity' header
2. Visit it in Minefield.

Actual Results:  
Minefield displays an error message:

"Content Encoding Error

The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression. Please contact the website owners to inform them of this problem.
    *   Please contact the website owners to inform them of this problem."


Expected Results:  
The text or image should display as normal.

This works with no problems in 1.5.0.4 and others browsers I've tested (Safari 2.0.3, IE 7, etc).

See also bug 337901, which reports the same error message on an actually illegal value. I've gone ahead and reported this as a separate bug because 'identity' actually is the default value for Content-Encoding, and thus probably _ought_ to work.

The spec does say that the 'identity' value 'SHOULD NOT' be used:

"identity The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept- Encoding header, and SHOULD NOT be used in the Content-Encoding header."

however it doesn't say it 'MUST NOT' be used. While there isn't a requirement to accept this explicit header, I don't see a reason to reject it either.

In our case we had been using it in a PHP app (MediaWiki) to override a 'Content-Type: gzip' header set by a default compression handler which is canceled out when sending an image file. A sample PHP script to reproduce this is:

<?php
header('Content-Type: image/png');
header('Content-Encoding: identity');
readfile('some_file.png');
?>

We've worked around the issue by calling header('Content-Encoding:'), which removes the header entirely instead of overriding it with the default value.

Comment 1

[WADA:World Anti-bad-Duping Agency]

rfc2616 section 3.5 says;
> 3.5 Content Codings
>(snip)
> identity
>   The default (identity) encoding; the use of no transformation whatsoever.
>   This content-coding is used only in the Accept- Encoding header,
>   and SHOULD NOT be used in the Content-Encoding header.
 ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5 )

=> INVALID

Comment 2

[Boris Zbarsky [:bzbarsky]]

ccing networking peers.  Darin, biesi, should we handle "identity" in responses?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

didn't we use to support it?

Comment 4

[Boris Zbarsky [:bzbarsky]]

We used to treat any unknown encoding as "identity".

Comment 5

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

URL WFM.