User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 20131207004003 Steps to reproduce: User is not notified when content-length is invalid as it should be as said in rfc 2616 section 4.4 " When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected." This case happenned during an http download with a http proxy server (a bad one !) which closed the connection properly (with tcp flag FIN) before the response is complete. The Content-Length was bigger than the body length (because body was incomplete). I wrote a naive http server in java which produce the exact same problem (attachement), generating a content-length bigger than body length. This code can test with or without gzip encoding, and can do the same with incomplete response using Transfer-Encoding chunked. I found a bug in bugzilla that seem to be the same (325949). But it is not completely : I tested it in firefox 27, and extra content is not shown. Actual results: The file received was truncated, and the error was ignored. Expected results: Should has been notified of the error (in order to do a retry/resume for example). I look in the code, and see that error is detected in nsHttpTransaction.cpp (field mResponseIsComplete). But the error seem to be used only for pipelinning calculation.

in order to keep interoperability high, we do this under some circumstances on purpose.

It should be greate to have the ability to access this field mResponseIsComplete via nsIHttpChannel for example. Now, as a developper using channels, I can't know when a stream is truncated.

I reopen this ticket because I tested it with Google Chrome. Google dont have the same problem of interoperability ! The error is shown as it must be according to the rfc. Instead of the content sent by the server, I can see an error page. Like I said, if it is really a problem to consider it as an error, the information should be available in nsIHttpChannel for example.

(In reply to Patrick McManus [:mcmanus] from comment #1) > in order to keep interoperability high, we do this under some circumstances > on purpose. Then how can we fix bug 237623 without error propagation from Necko?

I believe paolo was going to check the content length of the download. he had a plan discussed at a work week in mountain view.

Thanks for the clarification.