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 577386 - soup-message-io needs to set an error if the response body is truncated
soup-message-io needs to set an error if the response body is truncated
Status: RESOLVED OBSOLETE
Product: libsoup
Classification: Core
Component: HTTP Transport
2.25.x
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2009-03-31 01:20 UTC by Gustavo Noronha (kov)
Modified: 2018-09-21 16:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
small test case (1.96 KB, application/octet-stream)
2009-03-31 01:21 UTC, Gustavo Noronha (kov)
  Details
[PATCH] Consider corrupted or truncated data as EOF (419 bytes, patch)
2009-04-03 01:52 UTC, Diego Escalante Urrelo (not reading bugmail)
committed Details | Review

Description Gustavo Noronha (kov) 2009-03-31 01:20:04 UTC
Diegoe found this while using Epiphany/WebKit. The problem happens with the following site:

https://webaloe.ulima.edu.pe/portalUL/

Here's the relevant WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=24954

The problem seems to happen because the server gives us a 302, and sends back a Connection: close, but sends a fair amount of \r\n's as a body, which confuses libsoup. I'm going to attach a small test case reproducing the problem.
Comment 1 Gustavo Noronha (kov) 2009-03-31 01:21:30 UTC
Created attachment 131741 [details]
small test case
Comment 2 Dan Winship 2009-04-03 01:07:02 UTC
soup_gnutls_read() is getting GNUTLS_E_UNEXPECTED_PACKET_LENGTH at the end of the response, so it returns G_IO_STATUS_ERROR, so soup-message-io.c ends up bailing out, so got-body never gets emitted (so the redirect doesn't get processed), but then that code path is broken and it doesn't change the message in any way to indicate that an error occurred.

So, the web server is doing something broken in terms of how it ends its response, but I guess if other web browsers deal with it we should too.
Comment 3 Diego Escalante Urrelo (not reading bugmail) 2009-04-03 01:52:49 UTC
Created attachment 131963 [details] [review]
[PATCH] Consider corrupted or truncated data as EOF


Emitting G_IO_STATUS_ERROR instead was causing HTTPS redirects fail in WebKit.
This fixes bug #577386.
---
 libsoup/soup-gnutls.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)
Comment 4 Dan Winship 2009-04-03 14:35:24 UTC
committed the fix. will be in 2.26.1

You can close the downstream bug, but I'm leaving this one open to deal with the other problem I mentioned on IRC; in the event of an actual SSL error (or possibly certain other network I/O errors), soup-message-io doesn't set the message status to indicate that the response is truncated. That still needs to be fixed.
Comment 5 Christophe Gillette 2009-06-22 21:15:10 UTC
Hi,
It seems that the issue I am seeing is related to the last comment:
gnutls_handshake() fails, and therefore returns an error. io_error sets the correct error, but it gets cleared in soup_message_io_finished() by a call to soup_message_io_cleanup(). The listener to the restarted signal is not informed of the error.
As a consequence, Webkit indefinitely queries the same message over and over.
Comment 6 Dan Winship 2015-02-10 11:57:35 UTC
[mass-moving all "UNCONFIRMED" libsoup bugs to "NEW" after disabling the "UNCONFIRMED" status for this product now that bugzilla.gnome.org allows that. bugspam-libsoup-20150210]
Comment 7 GNOME Infrastructure Team 2018-09-21 16:02:25 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libsoup/issues/22.