Just to add another data point, I cannot reproduce the issue on Chrome OS, beta channel. Here's my stack:

> Version 49.0.2623.75 beta (64-bit)
> Platform 7834.53.0 (Official Build) beta-channel samus
> Firmware Google_Samus.6300.174.0

I've extracted the .zip and hosted it online to make testing easier: http://159.203.140.176:3281/

My console output looks like this:

> GET http://159.203.140.176:3281/IDontExist.jpg 404 (File not found) [frame.html:16]
> Ive loaded inside the frame [frame.html:7]
> Ive loaded outside the frames [(index):7]

Hi,
Where can I get this beta release to see if i can reproduce with it?

Also have you been able to reproduce on the stable release version of
Chrome 49 that I logged?

Thanks,
Gary

Hey Gary,

Chrome OS allows you to change channels via the preferences, but unfortunately I'm unable to switch channels on that machine (work stuff). Sorry about that.

I was able to use my Macbook Pro (OS X 10.10.5) to test the stable channel (Chrome  49.0.2623.87 (64-bit)), but I'm still unable to reproduce your bug.


Are you showing the same error on my host (http://159.203.140.176:3281/)? I might try incognito mode too, on the off chance you haven't tested that. If that doesn't work, I might try the beta channel, available here: https://www.google.com/chrome/browser/beta.html

Cheers,
Christian

Hi Christian,

I'm on that 49.0.2623.87 (64 bit) build on both my Mac and my Windows 10
box and can see the issue on my locally hosted reproducible. I've just
tested your hosted reproducible and it works fine from there. No network
error. But when I try from my Jboss 6.2 (RedHat) system I see the problem
again.

I've just asked my IT department to set up a hosted JBoss environment and
expose it to the outside so we can access the same reproducible. I'll also
in the mean time try the beta channel.

Could this be a platform specific issue? Or perhaps a difference with an
Intranet hosted site and a WAN based site?

Thanks,
Gary

Update: Just tested the Beta Channel against my internal hosted Jboss and get the same problem. I test build 48.x Chrome, IE 11 or Safari and don't see the problem.

I'll update once my IT department has the exposed site.
Thanks,
Gary

Hi Christian,

I now have an external reproducible accessible to you. Please try:
http://abdms.lims.com:8070/dms/TestChrome/

I have tried from Windows 7 Chrome 49.0.2623.87 (64bit), Mac OS X Chrome  49.0.2623.87 (64bit) and Windows 10 Chrome 49.0.2623.87 (64bit) and it is reproducible. When I try Chrome 48 it is not reproducible.

Thanks,
Gary

Looks like your server returns a non GZIP encoded response, but states that it is GZIP encoded.

Why that causes an infinite-loading image, is another question, but your server is probably doing some faulty stuff there.


From chrome:net-internals -
47079: URL_REQUEST
http://abdms.lims.com:8070/dms/TestChrome/IDontExist.jpg
Start Time: 2016-03-10 11:56:00.431

t=169817 [st=    0] +REQUEST_ALIVE  [dt=20012]
t=169818 [st=    1]    URL_REQUEST_DELEGATE  [dt=0]
t=169818 [st=    1]   +URL_REQUEST_START_JOB  [dt=20011]
                       --> load_flags = 98560 (DO_NOT_USE_EMBEDDED_IDENTITY | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                       --> method = "GET"
                       --> priority = "IDLE"
                       --> url = "http://abdms.lims.com:8070/dms/TestChrome/IDontExist.jpg"
t=169818 [st=    1]      URL_REQUEST_DELEGATE  [dt=0]
t=169818 [st=    1]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=169818 [st=    1]      HTTP_CACHE_OPEN_ENTRY  [dt=0]
t=169818 [st=    1]     +HTTP_CACHE_ADD_TO_ENTRY  [dt=20000]
t=169821 [st=    4]        URL_REQUEST_SET_PRIORITY
                           --> priority = 1
t=189818 [st=20001]     -HTTP_CACHE_ADD_TO_ENTRY
                         --> net_error = -409 (ERR_CACHE_LOCK_TIMEOUT)
t=189819 [st=20002]      URL_REQUEST_DELEGATE  [dt=0]
t=189819 [st=20002]     +HTTP_STREAM_REQUEST  [dt=3]
t=189819 [st=20002]        HTTP_STREAM_REQUEST_STARTED_JOB
                           --> source_dependency = 47093 (HTTP_STREAM_JOB)
t=189822 [st=20005]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                           --> source_dependency = 47093 (HTTP_STREAM_JOB)
t=189822 [st=20005]     -HTTP_STREAM_REQUEST
t=189822 [st=20005]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=1]
t=189822 [st=20005]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                           --> GET http://abdms.lims.com:8070/dms/TestChrome/IDontExist.jpg HTTP/1.1
                               Host: abdms.lims.com:8070
                               Proxy-Connection: keep-alive
                               Accept: image/webp,image/*,*/*;q=0.8
                               User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
                               Accept-Encoding: gzip, deflate, sdch
                               Accept-Language: en-US,en;q=0.8,en-GB;q=0.6,he;q=0.4
t=189823 [st=20006]     -HTTP_TRANSACTION_SEND_REQUEST
t=189823 [st=20006]     +HTTP_TRANSACTION_READ_HEADERS  [dt=6]
t=189823 [st=20006]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=6]
t=189829 [st=20012]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                           --> HTTP/1.1 404 Not Found
                               Server: Apache-Coyote/1.1
                               Expires: Fri, 11 Mar 2016 21:27:14 GMT
                               Cache-Control: max-age=3600
                               Content-Encoding: gzip
                               Content-Type: text/html;charset=utf-8
                               Date: Thu, 10 Mar 2016 09:56:06 GMT
                               Content-Length: 1120
                               Age: 27
                               Via: 1.1 corp.proxycorp.com
t=189829 [st=20012]     -HTTP_TRANSACTION_READ_HEADERS
t=189829 [st=20012]      URL_REQUEST_DELEGATE  [dt=0]
t=189829 [st=20012]      URL_REQUEST_FILTERS_SET
                         --> filters = "FILTER_TYPE_GZIP"
t=189829 [st=20012]   -URL_REQUEST_START_JOB
t=189829 [st=20012]    URL_REQUEST_DELEGATE  [dt=0]
t=189829 [st=20012]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=189829 [st=20012]    FAILED
                       --> net_error = -330 (ERR_CONTENT_DECODING_FAILED)
t=189829 [st=20012] -REQUEST_ALIVE
                     --> net_error = -330 (ERR_CONTENT_DECODING_FAILED)

Just found another interesting fact. When I first open chrome and navigate to the reproducible the infinite loop occurs (see screenshots attached). However when I open a second tab and navigate to the same URL it still takes longer than it should but does eventually return with the ERR_CONTENT_DECODING_FAILED error (see screenshot).
I'll investigate the GZIP compression now and report back.
Thanks,
Gary

Deleted: FirstLoad.png 113 KB

	FirstLoad.png 113 KB View Download

Deleted: SecondTabLoad.png 122 KB

	SecondTabLoad.png 122 KB View Download

I used Fiddler 2 and looked at the request and response for all the browsers. They are identical but we can see for the missing image the JBoss internals returns back a 404 HTML error message. However we see that the Jboss compression filter is still forcing the encoding header to GZIP even though it is raw HTML. I will need to work with RedHat to work out why this is happening. 

However the important fact, is that this worked in build 48 of chrome and it works on every other browser. It would seem that in build 49 it blindly tries to decode the GZIP even if it is not GZip and causes an infinite loop.

Cheers,
Gary

Deleted: Request .pdf 410 KB

Request .pdf 410 KB Download

Applying filters label due to the gzip mention. 

Helen, do you remember any changes that might have caused this?  I scanned the git logs for net/filter and didn't spot anything, but this totally sounds like something that might have happened cleaning up the filter code.  I'm not even sure I consider it a bug :-}.  But I'd like to find the change before we do that evaluation.

(Specifically, what might have caused the regression discussed in c#11.)

Nothing registered. I will try doing a bisect.

Did a bisect. The regression is called by URLRequestJob::ReadRawData refactoring (see below). However, this regression is fixed (at least in canary). Randy, how should we proceed?


=========================

You are probably looking for a change made after 360326 (known good), but no later than 360333 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/03eaf889ebe699c3a5af069d4a2ef2206c6431ad..1c6c5dc9911b507ac286b25d8bcfe454357ea0bd

Ah, that makes sense.  I think if the regression is fixed in canary, we don't need to do anything.  But I'm curious: What aspects of the refactor caused the problem?  This behavior strikes me as potentially wrong, but it being in Chrome and all the other browsers suggests there's something I'm missing.  How does canary/M48 handle things such that a content encoding of gzip on uncompressed data works?

And thanks for digging into this and figuring it out!

Randy:  Remember, you reviewed my small state machine cleanup CL that happened to fix this (And had a unit test for this exactly issue as well).  See https://codereview.chromium.org/1563633002

So this is basically a duplicate of  issue 575213 , right?
Perhaps we should mark it as such?

Hi,

Thanks for looking into this. Great progress.

So it would seem that you have already identified the refactor problem and
have fixed it under the other issue. Is this the case? If so when can we
expect to see it appear in the stable release?

In the meantime I have told our support team to advise customers who see
the problem to first make sure the images on their pages do exist and
secondly to disable the gzip filter if they are not able to alter the image
paths.

Thanks,
Gary

Yes. But M49 stable release won't have this fix, according to https://omahaproxy.appspot.com/. Matt, is a merge needed?

Without a merge, it'll be in M50, which is going to hit stable around mid-April (see https://www.chromium.org/developers/calendar for *estimated* Chrome milestone releases to stable).

So mid April without the Merge. What would it take to persuade you to do
the merge to get it sooner ;) I can make good cakes, but may not package
well from UK to US ;)

Thanks,
Gary

Ahh, just assumed it would be in M49, given how far back I landed the patch, but looks like you're right.

Since this is a fairly rare case in how we deal with one particular type of buggy server response, I don't think it's worth merging the fix.

We tend to be very conservative with merges, particularly once a branch has gone stable (According to the calendar above, M49 is estimated to go to stable very soon).  The main things that matter for merge decisions are impact and security.

This doesn't seem to have much impact.  Before the regression, about 0.0015% of main frame loads resulted in this error, and 0.011% subframe requests did.  After the regression, failures maybe dropped by 1/3rd?

And doesn't seem like a security issue.

Chrome 49 has shipped already, a week or two ago.