User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.51 Safari/535.2 Steps to reproduce: Went to a page I wrote that serves custom headers with php. Actual results: I got a Corrupted Content Error and was unable to find any more information on the error from Firefox. Testing with curl -v I got the following headers: HTTP/1.1 200 OK Date: Thu, 29 Sep 2011 01:26:49 GMT Server: Apache Content-Disposition: inline; filename="image_65x44.png" Cache-Control: maxage=3600 Expires: Thu, 29 Sep 2011 02:26:49 GMT Content-Length: 2945; Content-Type: image/png Expected results: No error or at lest some information as to debug the message such as Error Console. I removed the ; from Content-Length and it worked fine.
Can you temporarily put the bad script online on some test installation and give us the URL?
Here is a example with several different variants. Note the tetx/plain works fine but image/png and image/jpeg fail with "Corrupted Content Error" and nothing in Error Console, Web Console or Firebug to indicate the error. http://test.scotepi.net/ff690202/
This looks like a duplicate of bug 683699, but if this is affecting multiple sites maybe we should look into changing the behavior here..
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
You would need telemetry or something to see how many sites are affected. The reporter probably doesn't know any. He did it by mistake and Firefox did catch it, by not working. He would be satisfied with an error message in Error console, allowing this syntax (ignoring garbage) is not necessary if you decided that way in bug 683699.
It is reproducible, there is an example in my website http://zuchini.sslmx.net/cgi-bin/firefox/firefox_dl_fail.pl http://zuchini.sslmx.net/cgi-bin/firefox/firefox_dl.pl The only difference is the semi-colon after the content-length diff -c shows this *************** *** 1,7 **** HTTP/1.0 200 OK ! Date: Sat, 01 Oct 2011 19:51:33 GMT Server: Apache ! Content-Length: 24168; Content-Type: image/jpeg; X-Cache: MISS from zuchini.homeip.net Proxy-Connection: close --- 1,7 ---- HTTP/1.0 200 OK ! Date: Sat, 01 Oct 2011 19:51:40 GMT Server: Apache ! Content-Length: 24168 Content-Type: image/jpeg; X-Cache: MISS from zuchini.homeip.net Proxy-Connection: close
1. Confirming that the "...firefox_dl_fail.pl" URL produces a "Corrupted Content Error" page. 2. Is semicolon after Content-type legal? I think we were talking about semicolon only after Content-length. Vijay, that semicolon was not in the original report. However, the "...firefox_dl.pl" also contains the semicolon and it works fine. 3. What I noticed when analyzing the URLs in Firefox is that Web console can't handle the HTTP reply with semicolon after Content-length. The message in Web console is this: "[22:04:33.098] GET http://zuchini.sslmx.net/cgi-bin/firefox/firefox_dl_fail.pl [undefined 325ms]" And that is incorrect, Firefox received a reply, supposedly with HTTP 200 OK. Clicking on the line shows the window with details. The reply from server is completely missing there. I think this Web console should handle this and show what the sender sent. It is the main job of it and will be referenced exactly when server sends something bad. Should this be a new bug?
Status: UNCONFIRMED → NEW
Ever confirmed: true
> I think this Web console should handle this and show what the sender sent. Should > this be a new bug? Yes. It's been filed as bug 688345. Thanks.
> Is semicolon after Content-type legal? The RFC doesn't permit anything but numeric values for Content-Length: however we seem to be in the vanguard of actually enforcing this: --- RFC 2616, section 14.13 Content-Length The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. Content-Length = "Content-Length" ":" 1*DIGIT
Well, I was asking about content-TYPE.
Any value of Content-Type should not be relevant to the CORRUPTED_CONTENT_ERROR .. CCE should only be for illegal varations of content-length, location, and content-disposition.
The currently relative part of HTTPbis is: If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and MUST be treated as an error to prevent request or response smuggling. If a browser chooses to ignore the semicolon, I'm concerned we'll need to start defining an algorithm that describes how to normalise Content-Length values; e.g., what about the following? Content-Length: 10! Content-Length: a10 Content-Length: asdf10qwer Content-Length: a10b20c and so on. If people believe that there is not an underlying security issue in handling invalid Content-Length headers, *and* there are a fair number of these out there, it's worth discussing. Otherwise, my .02 is that any effort should be focused on making the error more user- (and developer-) friendly, FWIW.
(In reply to Patrick McManus from comment #10) > Any value of Content-Type should not be relevant to the > CORRUPTED_CONTENT_ERROR .. CCE should only be for illegal varations of > content-length, location, and content-disposition. Patrick, can you argue why, and how should we behave when an invalid value was found?
The RFC-mandated behavior (no semicolon or anything else but a numeric length) has been out in FF 9 for a while and the world hasn't ended. So at this point I think it's time for any remaining rogue servers to implement the spec correctly.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 683699
The core of the issue was that there is no error message given by Firefox to help someone debug why they are getting this error. As of 9.0.1 I still didn't see any specific message in error console.
scotepi, You're right we have more work to do with the error reporting for this: that's being handled in bug 688345 (and possibly some other work).
You need to log in before you can comment on or make changes to this bug.