After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 676477 - Broken chunked encoding handling
Broken chunked encoding handling
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: HTTP Transport
2.39.x
Other Linux
: Normal major
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2012-05-21 09:35 UTC by Sergio Villar
Modified: 2012-08-06 14:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sergio Villar 2012-05-21 09:35:02 UTC
Google's live search stops working after typing a couple of words. Looks like chunked encoding got broken in libsoup's master
Comment 1 Sergio Villar 2012-05-23 11:37:35 UTC
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.
Comment 2 Dan Winship 2012-05-23 13:58:39 UTC
(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...
Comment 3 Sergio Villar 2012-05-23 14:28:06 UTC
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...
Comment 4 Sergio Villar 2012-05-23 15:59:25 UTC
(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.
Comment 5 Dan Winship 2012-05-24 20:16:58 UTC
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.
Comment 6 Sergio Villar 2012-05-25 10:45:11 UTC
(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.
Comment 7 Sergio Villar 2012-05-28 10:11:23 UTC
(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.
Comment 8 Sergio Villar 2012-05-29 18:56:05 UTC
(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.
Comment 9 Sergio Villar 2012-05-30 11:35:50 UTC
(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.
Comment 10 Dan Winship 2012-05-30 13:07:41 UTC
(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
Comment 11 Dan Winship 2012-05-30 13:08:05 UTC
DOH! ok, I guess we've got to start using the ASSIGNED state... :-}
Comment 12 Dan Winship 2012-08-06 14:20:23 UTC
so this did turn out to be fixed