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 629088 - Support 302 + "<meta http-equiv='REFRESH'" redirections
Support 302 + "<meta http-equiv='REFRESH'" redirections
Status: RESOLVED NOTGNOME
Product: libsoup
Classification: Core
Component: HTTP Transport
2.31.x
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2010-09-08 16:49 UTC by Sergio Villar
Modified: 2010-09-08 17:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
First attempt to fix the bug (3.18 KB, patch)
2010-09-08 16:58 UTC, Sergio Villar
none Details | Review

Description Sergio Villar 2010-09-08 16:49:27 UTC
Comes from https://bugs.webkit.org/show_bug.cgi?id=29299

As it's a libsoup issue I'm moving that here for further discussion
Comment 1 Sergio Villar 2010-09-08 16:58:48 UTC
Created attachment 169780 [details] [review]
First attempt to fix the bug

This is a patch that fixes the bug. The idea is that first we detect 302 redirects without Location header when headers are received. If that happens then we check if there is something in the body in the sniffed data and fake the status of the message that becomes SOUP_STATUS_OK. That way clients will load the html code and the redirect will take place.

Things I don't like a lot:
   * I'm assuming that everytime we get a 302 without Location header and something in the body it means that is an awful server performing a clunky redirection. Maybe we could verify that the body is an HTML doc with the meta http-equiv=REFRESH ?
   * Changing the status of the message to fake clients, but is there a better way to do that?
Comment 2 Dan Winship 2010-09-08 17:54:51 UTC
I think this is just working around webkit-gtk's own optimizations; libsoup indicates that it has failed to process the redirect itself by completing the message with a final status of 302. But ResourceHandleSoup will have already thrown away the message body by that point... But that's not libsoup's fault.

A better fix would probably be to extend ResourceHandleSoup's existing SOUP_STATUS_UNAUTHORIZED special case to cover all statusWillBeHandledBySoup() codes. So in gotHeadersCallback(), call soup_message_body_set_accumulate(msg->response_body, TRUE), and then in finishedCallback(), if the final status code is still a statusWillBeHandledBySoup() code, then apparently it *wasn't* handled by soup, so webkit should handle it itself (as in the current status_code == SOUP_STATUS_UNAUTHORIZED case).