Remove didReceiveAuthenticationChallenge() from SubresourceLoaderClient.
authorjaphet@chromium.org <japhet@chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 23 Sep 2011 01:12:38 +0000 (01:12 +0000)
committerjaphet@chromium.org <japhet@chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 23 Sep 2011 01:12:38 +0000 (01:12 +0000)
commita1a4e6d9d359ba42741c6beb8db91bb169ef0338
tree6becfbe1aed394e47bb79d1a91973ae3b868fde7
parentbdf0bf018f3e37f1cbb758026a0351649b3ef91c
Remove didReceiveAuthenticationChallenge() from SubresourceLoaderClient.
Instead, add a load-specific policy for showing the user authentication
challenge down to ResourceLoaderOptions and enforce it in ResourceLoader.
https://bugs.webkit.org/show_bug.cgi?id=65330

Reviewed by Alexey Proskuryakov.

No new tests, refactor only.

* loader/DocumentThreadableLoader.cpp:
* loader/DocumentThreadableLoader.h:
* loader/MainResourceLoader.cpp:
* loader/NetscapePlugInStreamLoader.cpp:
* loader/ResourceLoadScheduler.h:
* loader/ResourceLoader.cpp:
(WebCore::ResourceLoader::didReceiveAuthenticationChallenge):
   For resource types that always send a challenge to the embedder,
   this patch doesn't change anything. For those that don't, we will
   always try to continue without credentials when they are forbidden
   and the platform supports it.
   When continuing without credentials was initially implemented in
   DocumentThreadableLoader, we sent the ThreadableLoaderClient a didFail(),
   then canceled the SubresourceLoader. This was necessary because of the
   quirks of ThreadableLoader cancellation (we sever the client/loader connections
   before the load actually cancels), but a simple didFail() should suffice at
   the ResourceLoader layer.
* loader/ResourceLoaderOptions.h:
* loader/SubresourceLoader.cpp:
* loader/SubresourceLoader.h:
* loader/SubresourceLoaderClient.h:
* loader/cache/CachedResource.cpp:
* loader/cache/CachedResourceLoader.cpp:
* loader/cache/CachedResourceLoader.h:
* loader/icon/IconLoader.cpp: The ResourceLoader implementation of
    didReceiveAuthenticationChallege means that IconLoader will now
    try to continue with credentials on platforms that support it,
    rather than just canceling outright. We still will never prompt
    for authentication for icons.
* loader/icon/IconLoader.h:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@95768 268f45cc-cd09-0410-ab3c-d52691b4dbfc
16 files changed:
Source/WebCore/ChangeLog
Source/WebCore/loader/DocumentThreadableLoader.cpp
Source/WebCore/loader/DocumentThreadableLoader.h
Source/WebCore/loader/MainResourceLoader.cpp
Source/WebCore/loader/NetscapePlugInStreamLoader.cpp
Source/WebCore/loader/ResourceLoadScheduler.h
Source/WebCore/loader/ResourceLoader.cpp
Source/WebCore/loader/ResourceLoaderOptions.h
Source/WebCore/loader/SubresourceLoader.cpp
Source/WebCore/loader/SubresourceLoader.h
Source/WebCore/loader/SubresourceLoaderClient.h
Source/WebCore/loader/cache/CachedResource.cpp
Source/WebCore/loader/cache/CachedResourceLoader.cpp
Source/WebCore/loader/cache/CachedResourceLoader.h
Source/WebCore/loader/icon/IconLoader.cpp
Source/WebCore/loader/icon/IconLoader.h