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?

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).