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 571283 - libsoup does not handle <LF><LF> between http response headers and body.
libsoup does not handle <LF><LF> between http response headers and body.
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: HTTP Transport
2.25.x
Other All
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
: 575530 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-02-11 08:55 UTC by Pontus Oldberg
Modified: 2009-03-24 23:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch that solves the problem. (8.31 KB, patch)
2009-02-11 08:58 UTC, Pontus Oldberg
needs-work Details | Review
smaller patch to accept LF LF, doesn't change SoupSocket API (4.02 KB, patch)
2009-03-18 18:02 UTC, Dan Winship
none Details | Review

Description Pontus Oldberg 2009-02-11 08:55:22 UTC
Please describe the problem:
When writing an application that will read parameters from security cameras it was discovered that the cameras sends back an invalid response to libsoup. The cameras separates the http response headers from the body with an <LF><LF> sequence instead of the correct <CR><LF><CR><LF> which causes libsoup to report it as a corrupt response. Even though the cameras are sending a corrupt http response we would still like to use libsoup so I have prepared a patch that solves the problem. It might not be the right way to do it but it should give an indication on what is going on.

Steps to reproduce:
1. Send a http://get to an Axis security camera



Actual results:
libsoup will respond with an Error number 8, corrupt response.

Expected results:
That all should be OK

Does this happen every time?
Yes

Other information:
Comment 1 Pontus Oldberg 2009-02-11 08:58:07 UTC
Created attachment 128451 [details] [review]
Patch that solves the problem.

The fix was done in a hurry for us to be able to proceed in the project. I detect and correct the problem before the result is sent to the header parser instead of actually correcting the parser (Which seamed like a daunting task :-)
Comment 2 Dan Winship 2009-02-11 15:03:00 UTC
We can't change the API of soup_socket_read_until(), because it's used outside of libsoup (eg, by the gvfs ftp backend). We could add another method that takes multiple boundaries though... (though I don't like rewriting LF to CRLF inside SoupSocket either way...)

My long-term strategy for dealing with bad HTTP implementations is to let the app install I/O filters that get a chance to rewrite things before libsoup's parsers ever see them. (So in this case, the filter would rewrite the LF to CRLF before soup_socket_read_until() got a chance to compare it to the boundary string, so we'd still only need one boundary string.) Not sure when that will happen though.

I'm thinking about what the best fix here would be...
Comment 3 Dan Winship 2009-03-16 16:30:25 UTC
*** Bug 575530 has been marked as a duplicate of this bug. ***
Comment 4 Dan Winship 2009-03-18 18:02:43 UTC
Created attachment 130911 [details] [review]
smaller patch to accept LF LF, doesn't change SoupSocket API

Can you try out this patch?

Should be able to get this into 2.26.1
Comment 5 Priit Laes (IRC: plaes) 2009-03-18 18:24:09 UTC
(In reply to comment #4)
> smaller patch to accept LF LF, doesn't change SoupSocket API

It really fixed the problem with pg's (Arc?) webserver :P

Thanks :)
Comment 6 Dan Winship 2009-03-24 23:14:19 UTC
committed. This will be in 2.26.1