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] First draft 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] First draft 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. > Source/WebCore/platform/network/curl/ResourceHandleManager.cpp:404 > + String location = d->m_response.httpHeaderField("location"); This could probably be a const String&
+peavo
(In reply to comment #7) > +peavo 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.
Comment on attachment 222089 [details] First draft It contains different patchs
We've start working on this issue again.
Created attachment 322244 [details] patch
Attachment 322244 [details] did not pass style-queue: ERROR: Source/WebCore/ChangeLog:8: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] [5] Total errors found: 1 in 8 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 322246 [details] patch
Comment on attachment 322246 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=322246&action=review > Source/WebCore/platform/network/ResourceHandle.cpp:173 > +#if !PLATFORM(COCOA) && !USE(CFURLCONNECTION) && !USE(SOUP) && !USE(CURL) That's everyone. Let's just get rid of this. > Source/WebCore/platform/network/curl/ResourceHandleCurlDelegate.cpp:281 > + if ((request.httpMethod() == "GET") || (request.httpMethod() == "HEAD")) unnecessary parentheses. > Source/WebCore/platform/network/curl/ResourceHandleCurlDelegate.cpp:371 > + if (protocolHostAndPortAreEqual(m_currentRequest.url(), response().url())) { > + auto credential = getCredential(m_currentRequest, true); This is probably ok, but will likely need to be refined. It ignores the realm of basic authentication credentials, for example. > Source/WebCore/platform/network/curl/ResourceResponseCurl.cpp:154 > + return (httpStatusCode() == 301); parentheses unnecessary.
> > Source/WebCore/platform/network/curl/ResourceHandleCurlDelegate.cpp:371 > > + if (protocolHostAndPortAreEqual(m_currentRequest.url(), response().url())) { > > + auto credential = getCredential(m_currentRequest, true); > > This is probably ok, but will likely need to be refined. It ignores the > realm of basic authentication credentials, for example. Oh, okay. To think about realm, this place is too late for that check. Also actually the comparison of (protocol, host, port) sets was made in willSendRequest already. We'll discuss this one again. Thank you.
(In reply to Alex Christensen from comment #18) > > Source/WebCore/platform/network/curl/ResourceHandleCurlDelegate.cpp:371 > > + if (protocolHostAndPortAreEqual(m_currentRequest.url(), response().url())) { > > + auto credential = getCredential(m_currentRequest, true); > > This is probably ok, but will likely need to be refined. It ignores the > realm of basic authentication credentials, for example. Alex, I lost the point you mentioned. What is your point? We cannot compare to any realm at this point because we're about to send a new request. Authentication info will be added only if getCredential() returns valid information and that's when the url matches previous url who resulted with credential. Of course, getCredential() can be more clear if it returns std::optional<std::pair<String, String>>. Is that what you want?
Ah, I think you're right. returning an optional would be a little more clear, but I guess that's not critical to have in this same patch.
(In reply to Alex Christensen from comment #21) > Ah, I think you're right. returning an optional would be a little more > clear, but I guess that's not critical to have in this same patch. Okay. Can you give cq+?
Comment on attachment 322246 [details] patch Sure, remove extra parentheses soon.
Comment on attachment 322246 [details] patch Clearing flags on attachment: 322246 Committed r222728: <http://trac.webkit.org/changeset/222728>
All reviewed patches have been landed. Closing bug.
<rdar://problem/34772610>