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 583148 - Strange behavior from libsoup 2.26.1 + iPhoto
Strange behavior from libsoup 2.26.1 + iPhoto
Status: RESOLVED DUPLICATE of bug 582002
Product: libsoup
Classification: Core
Component: HTTP Transport
2.26.x
Other All
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2009-05-19 01:18 UTC by W. Michael Petullo
Modified: 2009-05-19 03:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description W. Michael Petullo 2009-05-19 01:18:12 UTC
Please describe the problem:
I'm seeing some strange behavior from libsoup 2.26.1. I am using libsoup to implement an HTTP server that interacts with an iPhoto client. I am finding that soup-socket.c:soup_socket_read_until "gives up" right before reading the "\r\n" boundary. As a result, soup-message-io.c:read_metadata() reads, for example, GET [uri] HTTP/1.1, but not the trailing "\r\n" during the first read_until call. The next call reads the "\r\n", causing read_metadata to return before reading the rest of the header data. Eventually, this causes a "Bad Request" state.

I have added print statements throughout the code and also looked at what is going on using wireshark. As far as I can tell, the client is making a valid request. All of the header data is there, but things just don't seem to work right.

I can not figure out what is going on. Libsoup 2.24.2.1 works fine with the same code (no other change).

Steps to reproduce:



Actual results:


Expected results:


Does this happen every time?
Yes.

Other information:
Comment 1 Dan Winship 2009-05-19 01:48:21 UTC
Yup, sorry. Fixed in 2.26.2, which is already on ftp.gnome.org and should be in the 2.26-based distros in a few days.


*** This bug has been marked as a duplicate of 582002 ***
Comment 2 W. Michael Petullo 2009-05-19 03:28:22 UTC
Confirmed fixed by 2.26.2.