690202 - Semicolon on Content-Length causes Corrupted Content Error

Status: RESOLVED DUPLICATE of bug 683699

(Core :: Networking: HTTP, defect)

Description

[scotepi]

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.

Comment 1

[:aceman]

Can you temporarily put the bad script online on some test installation and give us the URL?

Comment 2

[scotepi]

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/

Comment 3

[Boris Zbarsky [:bzbarsky]]

This looks like a duplicate of bug 683699, but if this is affecting multiple sites maybe we should look into changing the behavior here..

Comment 4

[:aceman]

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.

Comment 5

[Vijay Sarvepalli]

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

Comment 6

[:aceman]

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?

Comment 7

[Jason Duell]

> 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.

Comment 8

[Jason Duell]

> 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

Comment 9

[:aceman]

Well, I was asking about content-TYPE.

Comment 10

[Patrick McManus [:mcmanus]]

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.

Comment 11

[Mark Nottingham]

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.

Comment 12

[Honza Bambas (:mayhemer)]

(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?

Comment 13

[Jason Duell]

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.

Comment 14

[scotepi]

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.

Comment 15

[Jason Duell]

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).