This is expected behavior.  Without a final chunk, we have no idea if we have the entire file or not.  All we know is that the server closed the connection early.  The more magical non-spec compliant behavior browsers support, the more magical behavior not in the specs *every* browser has to support (And by definition, this behavior does not appear in the specs, so can only be figured out by trial and error, or looking at the source of other browsers), so we should only support extra stuff when it's absolutely necessary.

Also worth noting papering over this server bug encourages buggy, slow websites.  If we supported this behavior, some websites would "work", but only because they hit their connection timeout after we wait how many ever seconds for them to timeout the TCP connection for more chunks.  We've seen that behavior before - every chunked response would take something like 30 seconds, but "worked" on firefox because of this behavior.

The links at  https://crbug.com/501384#c3  refer to evidence that there are quite some servers that neglect to send a zero-length chunk. Ideally, servers would fix the problem by being standard-compliant. But failing that, there is nothing that Chrome users can do at the moment to see the content anyway.

I tested the above with Firefox 46, Safari 9 and Microsoft Edge 13, and all allow closed connections without the final zero-length chunk. Furthermore, if there was a delay between receiving the chunk and closing the connection, Chrome would render the content before printing ERR_INCOMPLETE_CHUNKED_ENCODING to the console (so there are now three examples where Chrome does show the content, the other two are in my first report: downloads and PDF reader).


Do you see any issues with accepting a response if the chunked response seems valid (except for the missing last chunk and CRLF) and the connection is closed soon-ish after receiving the last response (e.g. 1 second)? That would cover the case where servers close the connection immediately after sending the last data chunk (without the last zero-length chunk), and address your concern of delaying responses by 30 seconds (to be honest, I don't understand why treating closed connections as complete responses would stall requests for 30 seconds).

And to ease debugging, the error could be logged to the JS console and/or the network log (chrome://net-internals).

Hrm...At the HTTP layer, the network stack itself behaves identically, regardless of whether we see the close immediately or not - we read from the socket once and pass along everything we have.  Then if we see an error on the next read, we return it.  There could be differences at the SSL layer, or it could be higher up the chain, in the ResourceLoader stack...Or it could be in blink.  Regardless, doesn't seem to be an issue in the HTTP code.

And the issue with accepting the response as correct if we don't see the final chunk is we have have a partial download.  I'm not so concerned about the HTML case, as with everything else (Partial JS doesn't exactly work well, either).  It's an error, and should be surfaced as such.

OH, and it also shouldn't be cached as a full, correct response, for the same reason.

The decision seems to be made in HttpStreamParser::DoReadBodyComplete [1] (it is the only source of the error according to codesearch).

> And the issue with accepting the response as correct if we don't see the final chunk is we have have a partial download.

I think that this issue is already present in the current version of Chrome because of the special handling for downloads [2].


[1] https://chromium.googlesource.com/chromium/src/+/4cf6e0c8c2c179eaa6ba02583a2861a2f85ca474/net/http/http_stream_parser.cc#683
[2] https://chromium.googlesource.com/chromium/src/+/f6c40587bc9ee68ef8102992ea5c52cc8e0c6933/content/browser/download/download_request_core.cc#534

You said if the connection close is delayed, it's rendered - that decision is certainly not made in HttpStreamParser.  HttpStreamParser reads and returns all it can.  If the next read sees a connection close, it returns an ERR_INCOMPLETE_CHUNKED_ENCODING.  Doesn't have anything that would explain rendering partial content only if there's a delay before the error (Which I agree is weird).

Davidben has pointed out that 0.00% main frame and subresource loads result in ERR_INCOMPLETE_CHUNKED_ENCODING.  Given that extremely low rate, I'm going to go ahead and close the bug, and it seems like we should remove handling for it in the downloads code, too.

(There is also something to be said about security consequences for atomically-processed HTTPS resources like JavaScript if we don't do this thanks to close_notify in TLS being hopeless. Although I don't know if we enforce Content-Length being too long or HTTP/2 streams that don't end correctly. If we're in one of the cases where we must rely on transport close, we have no hope.)

Worth noting we have a similar hack for ERR_CONTENT_LENGTH_MISMATCH, which I'm not currently removing.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3d551ff2ccf5599ebc08037d34b2c1f3b3038874

commit 3d551ff2ccf5599ebc08037d34b2c1f3b3038874
Author: mmenke <mmenke@chromium.org>
Date: Thu Jun 23 01:21:01 2016

Remove hack to treat ERR_INCOMPLETE_CHUNKED_ENCODING error as success.

Only applies to downloads.  We were treating it as an error elsewhere
(Unless there's also a content-length header which has the same value
as the number of bytes the response decompresses to...Which is probably
a bug).

0.00% of main frame loads end with this error, so seems like this hack
isn't needed.

BUG= 501384 , 610126 

Review-Url: https://codereview.chromium.org/2092523002
Cr-Commit-Position: refs/heads/master@{#401499}

[modify] https://crrev.com/3d551ff2ccf5599ebc08037d34b2c1f3b3038874/content/browser/download/download_request_core.cc

Hi,

This change affects some of our vendor's websites for their downloads. Can you reconsider reverting the change for downloads, to allow ERR_INCOMPLETE_CHUNKED_ENCODING?
We are unable to confirm with all our vendors for them to fix their websites so for the interim, we are advising users to use IE or Firefox as an alternative.

Given the general difficulty of getting rid of old broken behavior for downloads, and how few complaints we've had about it since it went to stable a month ago (1, not including yours -  issue 649511 ), I don't think we should bring it back.  Note that if we brought back the broken behavior, and someone else anywhere on the entire planet added a new server that depended on the broken behavior, we'd be back in the same place with respect to them.

We are working in an enterprise environment supporting over 25000 users, this report is on behalf of these users.
It takes time to filter up user complaints and to then locate the cause of the issue. It is also reported to the vendor & they also have to triage on their side. That is why this is the first post from after 3 weeks (since 2016-09-07) of it being released.

You can see another report of this issue at https://productforums.google.com/forum/#!topic/chrome/8Aykgxa8kWU

The acceptance of a connection without trailing chunk is deemed apparently acceptable in IE and Firefox, likely due to:
https://en.wikipedia.org/wiki/Robustness_principle
    Be conservative in what you do, be liberal in what you accept from others (often reworded as "Be conservative in what you send, be liberal in what you accept").

Unfortunately, in the general case, that both requires all browsers to behave the same in unspecified cases, and in practice, browsers rarely agree in all corner cases, so it's best to stick to the spec, and fail on errors.

In this particular case, it can result in users with a corrupted file - we have no way to know the file is complete.  Also worth noting that being liberal in what you accept can result in security bugs (And this has happened in the past).  Is there a case where an attacker truncating a file being downloaded over a secure connection result in a security issue?  I can't tell you, and thinking about it makes my brain hurt.

 Issue 649511  has been merged into this issue.

 Issue 668171  has been merged into this issue.

 Issue 461213  has been merged into this issue.

 Issue 691479  has been merged into this issue.

Is there any potential to implement a flag allowing those of us who enjoy using Chrome to be able to do so on servers which aren't well behaved?  

In my use case, Amazon (they have a rather small bit of servers under the AWS banner) occasionally gives this error in a result where there isn't any file being transferred and there is no danger in treating incomplete data as complete when the server closes the connection early.

Having a flag to enable 'magical non-spec compliant behavior' to allow users to actually be able to use the same broken servers as other browsers, without forcing users to actually use those browsers, would probably fill many's definition of a feature which is absolutely necessary.  There's likely a lack of complaints, as people read the chilly and almost hostile reception to these reports and just don't bother.  

Other than from a principle standpoint, is it very difficult to implement a code path that can treat a suddenly terminated connection as "\0\r\n\r\n", based on whether a flag is set?

If it's Amazon, I imagine they could deploy a fix to their servers relatively quickly. Have you reported a bug with them?