CURL's ResourceHandleManager currently sets:
curl_easy_setopt(d->m_handle, CURLOPT_FOLLOWLOCATION, 1);
This means that HTTP redirects are handled behind the scenes by CURL. This incorrectly bypasses WebCore functionality and makes it difficult to fire the right signals and policy events at the right time. Moreover, it also bypasses WebCore's resources and data URL parsing capabilities.
http://software.hixie.ch/utilities/cgi/data/data is an example of a page that redirects to a data URL that's currently not working.
Patch coming up.
Removing the Gtk keyword, since GTK+ doesn't use curl anymore.
Too bad that patch never got added! :-)
We are currently working on it. : ) I already have a working implementation, so patch is coming soon.
(In reply to comment #3)
> We are currently working on it. : ) I already have a working implementation, so patch is coming soon.
Great, this bug should be assigned to you in this case.
Created attachment 222089 [details]
Sorry for the delay. I have worked on this, but I have been moved to another project and I won't have time work on this anymore.
Comment on attachment 222089 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=222089&action=review
This seems fine to me, but someone using the Curl backend more frequently should confirm it doesn't cause any problems.
> + String location = d->m_response.httpHeaderField("location");
This could probably be a const String&
(In reply to comment #7)
Will give it a test.
On Windows, I seem to be having some problems logging into hotmail with this patch.
There seems to be a redirect, but after that nothing happens, and the displayed page is empty, not sure why, though.
(In reply to comment #9)
> On Windows, I seem to be having some problems logging into hotmail with this patch.
> There seems to be a redirect, but after that nothing happens, and the displayed page is empty, not sure why, though.
I'm sorry, disregard my last comment. This behavior is exactly the same without the patch, so it must be caused by other changes.
Should we commit this one?
(In reply to comment #11)
> Should we commit this one?
I've been running with this patch, and have had some crashes in the network backend because the ResourceHandleClient has been used after deletion.