947846 - User Agent does not notify when content-length is invalid

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[samuel.gallacier]

Attachment: Naive server that produce the problem

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.

Comment 1

[Patrick McManus [:mcmanus]]

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

Comment 2

[samuel.gallacier]

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.

Comment 3

[samuel.gallacier]

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.

Comment 4

[Masatoshi Kimura [:emk]]

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

Comment 5

[Patrick McManus [:mcmanus]]

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.

Comment 6

[Masatoshi Kimura [:emk]]

Thanks for the clarification.