summaryrefslogtreecommitdiffstats
path: root/webkit/glue/weburlloader_impl.cc
Commit message (Collapse)AuthorAgeFilesLines
* DevTools: report correct content length for resources.yurys@google.com2009-11-021-4/+1
| | | | | | | | | | | | Currently lengthReceived always has the same value as dataLength when Safari calls ResourceHandle::didReceiveData. In Chrome expected content length is passed as lengthReceived parameter which leads to incorrect content length to be stored in InspectorResource. InspectorResource expects lengthReceived to be the length of current data chunk(see InspectorResource::addLength). So I changed lengthReceived parameter to be dataLength. Darin, I see your TODO comment at line 581 in http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/weburlloader_impl.cc?annotate=6296 (the comment was deleted later) so I think you are right person to review the change in weburlloader_impl.cc. Please look at weburlloader_impl.cc and feel free to leave devtools specific changes to Alex and Pavel. BUG=25213 TEST=DevToolsSanityTest.TestResourceContentLength Review URL: http://codereview.chromium.org/295041 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30725 0039d316-1c4b-4281-b951-d872f2087c98
* Make GetURLForDebugging return a const GURL.tony@chromium.org2009-10-281-3/+3
| | | | | | Review URL: http://codereview.chromium.org/326003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30388 0039d316-1c4b-4281-b951-d872f2087c98
* Do some cleanup of file path name handling.brettw@chromium.org2009-10-221-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | This started trying to cleanup DownloadManager::GenerateFilename which asserts if your system locale isn't UTF-8 (I ran into this when mine got messed up). The solution is to have GetSuggestedFilename return a FilePath rather than calling FromWStringHack. The rest of the patch is a result of trying to write GetSuggestedFilename in a reasonable way. I changed ReplaceIllegalCharacters to work on a FilePath::StringType. Some places in the code calling these functions got cleaner, some got messier. I think overall the ones that got messier are the ones doing sketchy things with paths and the ones that got cleaner are the ones doing things more properly. The only code here that gets called a nontrivial number of times is the weburlloader, and I think the new code does about the same number of string conversions overall (though on certain platforms the number will be higher or lower). BUG=none TEST=none Review URL: http://codereview.chromium.org/271056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29832 0039d316-1c4b-4281-b951-d872f2087c98
* Move FTP LIST parsing code to the renderer process.phajdan.jr@chromium.org2009-09-221-4/+20
| | | | | | | | | TEST=none BUG=none Review URL: http://codereview.chromium.org/210027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26860 0039d316-1c4b-4281-b951-d872f2087c98
* * Add appCacheManifestUrl data member to WebURLResponse, and use it to ↵michaeln@google.com2009-09-081-3/+2
| | | | | | | | | | | | detect 'foreign' entries. * Complete the 'contextID' to 'hostID' renaming since that terminology is now used in webcore ResourceRequest. This patch depends on a corresponding webkit change in the chromium port.https://bugs.webkit.org/show_bug.cgi?id=28960 Review URL: http://codereview.chromium.org/201026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25646 0039d316-1c4b-4281-b951-d872f2087c98
* Add WebKit api support for allowing/disallowing storedlevin@chromium.org2009-08-261-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | credentials and cookies from being sent to along with a request. I added the parameter for credentials to WebURLRequestPrivate since it isn't in ResourceRequest for now and then checked all places that do WebURLRequest::toMutableResourceRequest() or WebURLRequest::toResourceRequest() to ensure that they were not loosing information. Right now, there is a non-orthogonal relationship between setAllowStoredCredentials and setAllowCookies which is a carry over from WebKit but I could change this to make setAllowStoredCredentials only refer to user name/password if it thought that this is better. TEST=Covered by layout tests. BUG=http://crbug.com/10961 Review URL: http://codereview.chromium.org/174495 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24555 0039d316-1c4b-4281-b951-d872f2087c98
* Retrofit the pre-existing appache message dispatching with the new WebKit ↵michaeln@google.com2009-08-211-1/+3
| | | | | | | | | | | | | APIs and concrete classes defined in our new appcache library, and get rid of the old files. There are many files in the CL, mostly to pickup constant values now defined in our new appcache library, and to reflect a terminilogy change (from 'context' to 'host'). TEST=some existing unit tests apply BUG=none Review URL: http://codereview.chromium.org/170003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24022 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a bunch of layout tests related to dumpResourceLoadCallbacks.darin@chromium.org2009-08-061-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | There are several changes included: 1- Fixed up some of the signatures of virtual methods on TestWebViewDelegate so that they actually get called. 2- Fudged the output of some of the events so that they match the WebKit Mac results. This means outputing NSError instead of WebError, etc. 3- Modified WebURLLoaderImpl to send a more meaningful redirect request. This allows some tests to observe that we are for example going to be issuing a POST request in response to a 307 redirect of a POST request. 4- Modified WebViewDelegate::WillSendRequest to take a redirect_response parameter so that the TestWebViewDelegate can log information about that. 5- Deleted a number of custom baselines that are now unnecessary! :-) 6- Removed some code from WebFrameLoaderClientImpl::dispatchWillSendRequest that was causing our setting for firstPartyForCookies to differ from Safari. This CL depends on WebKit r46820. R=dglazkov,abarth BUG=none TEST=none Review URL: http://codereview.chromium.org/164033 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22590 0039d316-1c4b-4281-b951-d872f2087c98
* Add plumbing for allowing the renderer to intercept and cancel redirects beforedarin@chromium.org2009-07-301-17/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | they are sent. A good portion of this CL is to support the new UI test. The IPC to notify the renderer of a redirect now includes a ResponseInfo struct allowing WebURLLoaderImpl to provide detailed response info (including response headers) to WebKit. This isn't strictly necessary, but I thought I'd include this to make the code more future proof. A cross origin restriction is added to SyncResourceHandler::OnRequestRedirected that mimics the code in WebCore/platform/network/cf/ResourceHandleCFNet.cpp. This is most unfortunate, and I filed a bug at bugs.webkit.org about the similar duplication of logic in WebCore. There seemed to be enough code paths leading to request cancellation at the ResourceDispatcher level that I couldn't easily ensure that a request only gets cancelled once. So, I added an is_cancelled flag to record if it is not necessary to send a ViewHostMsg_CancelRequest IPC. This avoids some warnings in the ResourceDispatcherHost. To support my UI test, I needed to change URLRequestMockHttpJob to know how to serve redirects. I moved URLRequestHttpJob::IsRedirectResponse to its base class, URLRequestJob so that the implementation could be shared. This revealed a minor bug in URLRequest. We were never resetting response_info_ upon following a redirect. I added this code consolidated similar code from URLRequest::Redirect and URLRequest::RestartWithJob into a new PrepareToRestart method. To support my UI test, I added a "hit count" field to URLRequestFilter, and I added an associated automation IPC to query the value. The test was a bit challenging to write because there is no way to tell the difference from JS. Before and after, it appears to JS as though the cross-origin redirect failed. However, the server can see the extra redirect request. So, I simply record the number of hits against URLs of the form http://mock.http/foo, and use that to observe if any extra requests were made. I implemented the new IPC message by extending the AutomationResourceMessageFilter. This allowed me to trap the IPC message on the IO thread where it is safe to probe the URLRequestFilter. I then changed the implementation of AutomationMsg_SetFilteredInet to work similarly. I revised URLRequestMockHTTPJob::GetOnDiskPath to support ports. This actually allowed me to reuse URLRequestMockHTTPJob to service URLs in different security origins. My test redirects from http://mock.http/ to http://mock.http:4000/. Please see the comments in cross-origin-redirect-blocked.html for details about how the test functions. R=brettw,wtc BUG=16413 TEST=covered by resource_dispatcher_host_uitest.cc Review URL: http://codereview.chromium.org/159370 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22067 0039d316-1c4b-4281-b951-d872f2087c98
* Don't call cancel on requests that have completed successfully.paul@chromium.org2009-06-251-1/+3
| | | | | | | | | | | | | | | | Calling cancel in this case causes an unnecessary cancel IPC message to be sent to the browser for every single URL we load, which then unsuccessfully tries to look up the request. This triggers the logs to fill up with the following message: "Canceling a request that wasn't found". It also makes pinkerton sad. TEST=Run in debug mode and notice the quiet output window BUG=14494. R=darin Review URL: http://codereview.chromium.org/146067 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19251 0039d316-1c4b-4281-b951-d872f2087c98
* Fix javascript-backslash.html layout test failure.darin@chromium.org2009-06-111-158/+228
| | | | | | | | | | | | | | | | The fix is to break WebURLLoaderImpl into two classes. It now has a reference counted inner class that is the ResourceLoaderBridge::Peer. This change allows the inner class to stick around after the loader has been destroyed. That is necessary since the Peer expects to still receive OnCompletedRequest after it calls Cancel on the bridge. R=dglazkov TEST=covered by layout test BUG=13786 Review URL: http://codereview.chromium.org/125002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18215 0039d316-1c4b-4281-b951-d872f2087c98
* Update WebKit to r44544.darin@chromium.org2009-06-091-16/+0
| | | | | | | | | | | | | | | | | | | | 1- WorkerThread::create() now takes a WorkerLoaderProxy parameter, which I implemented in a stub fashion on WebWorkerImpl. I'm sure the WebWorker guys will fix this up properly. 2- Removed expirationDate and setExpirationDate members of WebURLResponse consistent with their removal from WebCore::ResourceResponseBase. The corresponding logic for computing cache eviction time is now part of WebCore. 3- Added wtf/DateMath.{h,cpp} to the build. TEST=covered by existing tests, I hope! BUG=none R=eroman Review URL: http://codereview.chromium.org/119387 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17983 0039d316-1c4b-4281-b951-d872f2087c98
* Start using WebURLLoader, et. al. from the WebKit API.darin@chromium.org2009-06-091-0/+502
| | | | | | | | | | | | | | | | | | | | | | | | | | | Moves our ResourceHandle to webkit/api/src/ResourceHandle.cpp from webkit/glue/resource_handle_impl.cc. A portion of resource_handle_impl.cc was moved into weburlloader_impl.{h,cc}, which now contains our implementation of WebURLLoader. The annoying parts of this CL involve WebPluginImpl. I had to convert it over to using WebURLLoader instead of ResourceHandle so that MultipartResourceDelegate can be shared. There is some complexity in WebURLRequest / WebURLResponse to make it cheap to wrap a ResourceRequest / ResourceResponse. I think this is worth it since there is a lot of conversion between the two types. Originally reviewed here: http://codereview.chromium.org/113928 BUG=10038 TEST=covered by existing tests R=dglazkov Review URL: http://codereview.chromium.org/118438 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17962 0039d316-1c4b-4281-b951-d872f2087c98
* Revert WebURLLoader landing. Too many layout test failures.darin@chromium.org2009-05-301-502/+0
| | | | | | | | TBR=dglazkov Review URL: http://codereview.chromium.org/115973 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17293 0039d316-1c4b-4281-b951-d872f2087c98
* Fix layout test failures.darin@chromium.org2009-05-301-1/+2
| | | | | | | | | | | | | | | | | | | | 1- We need to be careful when converting from a null WebURL to a GURL since std::string(NULL, 0) crashes. 2- It turns out that in some layout tests, willSendRequest sets the request to null to indicate that we should not follow the redirect. In the few cases I debugged, this was happening because we were redirecting from "localhost" to "127.0.0.1". It seems like we probably need to change the hostname used to load HTTP based layout tests to match what the tests expect. For now, I just commented out the assertion since it was something that I had just newly added. BUG=none TEST=covered by layout tests TBR=dglazkov Review URL: http://codereview.chromium.org/115970 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17291 0039d316-1c4b-4281-b951-d872f2087c98
* Start using WebURLLoader, et. al. from the WebKit API.darin@chromium.org2009-05-301-0/+501
Moves our ResourceHandle to webkit/api/src/ResourceHandle.cpp from webkit/glue/resource_handle_impl.cc. A portion of resource_handle_impl.cc was moved into weburlloader_impl.{h,cc}, which now contains our implementation of WebURLLoader. The annoying parts of this CL involve WebPluginImpl. I had to convert it over to using WebURLLoader instead of ResourceHandle so that MultipartResourceDelegate can be shared. There is some complexity in WebURLRequest / WebURLResponse to make it cheap to wrap a ResourceRequest / ResourceResponse. I think this is worth it since there is a lot of conversion between the two types. BUG=10038 TEST=covered by existing tests R=dglazkov Review URL: http://codereview.chromium.org/113928 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17290 0039d316-1c4b-4281-b951-d872f2087c98