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 551190 - follows redirects on HEAD requests with GET
follows redirects on HEAD requests with GET
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: HTTP Transport
unspecified
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2008-09-07 02:39 UTC by Jonathan Matthew
Modified: 2008-09-07 17:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jonathan Matthew 2008-09-07 02:39:38 UTC
libsoup follows 'see other' and 'found' redirects with GET requests, regardless of the original method.  This can cause timeout problems in gio applications when dealing with moderately large files.

For a practical demonstration:

$ gvfs-info http://electronicexplorations.org/podpress_trac/feed/65/0/ElectronicExplorations_035_Dubstepforum_Hedz_Takeover_Sessions.mp3
 [this gives a 302 response]
 .. time passes ..

Error getting info: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Rhythmbox currently does the equivalent of this for podcast downloads, and many podcast hosting providers use 302 redirects as a matter of course.

The RFC does indicate that the client should issue a GET request in for these responses, but does that make sense when the original request was HEAD?  There isn't supposed to be any difference on the server side, the response SHOULD have identical headers, and the client doesn't want a response body.
Comment 1 Dan Winship 2008-09-07 17:55:05 UTC
(In reply to comment #0)
> The RFC does indicate that the client should issue a GET request in for these
> responses, but does that make sense when the original request was HEAD?

No, you're right, it doesn't make sense, and actually, the RFC only says that most clients "do" behave that way, not that they "should". 302 is supposed to mean "redirect with the same method", but many websites depend on having a 302 response to a POST be turned into a GET, so clients ignore the spec here. But obviously it doesn't make sense to turn a 302 response to a HEAD into a GET; in that case we should assume that the site is using 302 in the correct/original sense, and redirect using the same method.

Fixed in trunk. (The exact fix I used is that 302 redirects of "safe" methods [GET, HEAD, OPTIONS, PROPFIND] are redirected as-is, and 302 redirects of other methods are turned into GET.)

I guess this means I'll be putting out a libsoup 2.23.92 tomorrow.

Thanks for the bug report.