GNOME Bugzilla – Bug 676477
Broken chunked encoding handling
Last modified: 2012-08-06 14:20:23 UTC
Google's live search stops working after typing a couple of words. Looks like chunked encoding got broken in libsoup's master
After bisecting a bit, looks like it started to fail after a1ee9acd. It's the commit where we basically switched to stream based content decoding.
(In reply to comment #1) > After bisecting a bit, looks like it started to fail after a1ee9acd. It's the > commit where we basically switched to stream based content decoding. I poked at this a bit this morning, and it seems to be doing the chunked decoding correctly. However, I noticed that the live search responses are also gzipped, so I wonder if this is actually the same problem as 676478...
I have indeed(In reply to comment #2) > (In reply to comment #1) > > After bisecting a bit, looks like it started to fail after a1ee9acd. It's the > > commit where we basically switched to stream based content decoding. > > I poked at this a bit this morning, and it seems to be doing the chunked > decoding correctly. However, I noticed that the live search responses are also > gzipped, so I wonder if this is actually the same problem as 676478... I have indeed the same feeling, I am not sure which is the duplicated bug tough...
(In reply to comment #1) > After bisecting a bit, looks like it started to fail after a1ee9acd. It's the > commit where we basically switched to stream based content decoding. Actually we start to get the "instant search is not available" message after that commit but it keeps working. However after the legendary "o new brave world" commit (9effb5ca942) instant search stops working completely after some typing.
Pushed a fix to master, which also involves decoding, so these may be the same bug. There is still *something* wrong; I never get the "instant search is unsupported" message any more with this patch, but sometimes it does still stop working.
(In reply to comment #5) > Pushed a fix to master, which also involves decoding, so these > may be the same bug. > > There is still *something* wrong; I never get the "instant search is > unsupported" message any more with this patch, but sometimes it does > still stop working. I tried it, and indeed the instant search works fine again. Maybe we could track the other issues in bug 676478. I am still getting weird stuff while surfing b.g.o like resources not loaded, or garbage rendered as part of the web pages.
(In reply to comment #6) > (In reply to comment #5) > > Pushed a fix to master, which also involves decoding, so these > > may be the same bug. > > > > There is still *something* wrong; I never get the "instant search is > > unsupported" message any more with this patch, but sometimes it does > > still stop working. > > I tried it, and indeed the instant search works fine again. Maybe we could > track the other issues in bug 676478. I am still getting weird stuff while > surfing b.g.o like resources not loaded, or garbage rendered as part of the web > pages. I can reproduce the same issue in many different websites, I think all of them using https and chunked transfer encoding. For example https://addons.mozilla.org/en-US/firefox/ does not properly load the html for me.
(In reply to comment #7) > I can reproduce the same issue in many different websites, I think all of them > using https and chunked transfer encoding. For example > https://addons.mozilla.org/en-US/firefox/ does not properly load the html for > me. I had a quick look today at this issue and it turns out that it has something to do with content sniffing. If I remove the content sniffer stream from the streams stack, then everything works fine.
(In reply to comment #8) > (In reply to comment #7) > > I can reproduce the same issue in many different websites, I think all of them > > using https and chunked transfer encoding. For example > > https://addons.mozilla.org/en-US/firefox/ does not properly load the html for > > me. > > I had a quick look today at this issue and it turns out that it has something > to do with content sniffing. If I remove the content sniffer stream from the > streams stack, then everything works fine. OK, so finally I found the bug in gio. The converter input stream does not properly handle the case when it has some that already converted and needs to read some more from the base stream. I will file a new bug in glib, but first I need to verify why the gio unit tests were working fine.
(In reply to comment #7) > For example > https://addons.mozilla.org/en-US/firefox/ does not properly load the html for > me. Turns out that was not related to chunked encoding at all, it was GConverterInputStream's fault, and it's fixed in glib master (which I stole bug 676478 for). Leaving this open for now, but it may be FIXED
DOH! ok, I guess we've got to start using the ASSIGNED state... :-}
so this did turn out to be fixed