summaryrefslogtreecommitdiffstats
path: root/webkit/glue/weburlloader_impl.cc
Commit message (Collapse)AuthorAgeFilesLines
* Remove the fallback Mozilla code for parsing FTP LIST response.phajdan.jr@chromium.org2010-01-201-3/+13
| | | | | | | | | | | | | | | | | | The new parser seems to be compatible enough to do that. The Mozilla code was very helpful in the process of developing the new parser. Also add UI encouraging users to submit bug reports when we can't parse the listings, and an option to see the raw data sent by the server. This should allow us to fix remaining compatibility problems with very rare listing types or variations. When ?raw is found at the end of an FTP url and it is a directory listing, the parsing logic is bypassed and the data is displayed as-is with text/plain MIME type. TEST=none BUG=25520 Review URL: http://codereview.chromium.org/549053 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36632 0039d316-1c4b-4281-b951-d872f2087c98
* Enable JS detection of whether SPDY was used to load a web page.mbelshe@google.com2010-01-111-0/+1
| | | | | | | | | | | | Augments the loadTimes() API with a new field, "wasFetchedViaSpdy". BUG=31615 TEST=flip_network_transaction_unittest Review URL: http://codereview.chromium.org/518039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35943 0039d316-1c4b-4281-b951-d872f2087c98
* If we receive a redirect response, we should copy the http referer field ↵japhet@chromium.org2009-12-301-0/+9
| | | | | | | | | | | from the old request. BUG=7357 TEST=none Review URL: http://codereview.chromium.org/470010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35379 0039d316-1c4b-4281-b951-d872f2087c98
* Add a CreateBridge method to the ChildThread.jcampan@chromium.org2009-12-191-13/+15
| | | | | | | | | | | | | The intent is to allow unit-tests that use render view to override ChildThread::CreateBridge() to provide their own resource loading. This is used by the upcoming translate unit-test. BUG=None TEST=None Review URL: http://codereview.chromium.org/503032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35014 0039d316-1c4b-4281-b951-d872f2087c98
* WebKit update 51960:51976.eroman@chromium.org2009-12-111-2/+10
| | | | | | | | | | | | | | The change to weburlloader_impl.cc comes from: http://codereview.chromium.org/477008 Which is needed when picking up: http://trac.webkit.org/changeset/51967 TBR=dglazkov Review URL: http://codereview.chromium.org/487025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34341 0039d316-1c4b-4281-b951-d872f2087c98
* More removal of config.h and glue_util.h dependencies.darin@chromium.org2009-11-181-13/+11
| | | | | | | | | | | | | | I killed the #if ENABLE(WORKERS) defines in favor of always compiling that code because it is harmless to compile it when the underlying WebCore implementation is not compiled, thanks to the WebKit API. R=yaar BUG=none TEST=none Review URL: http://codereview.chromium.org/404023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32303 0039d316-1c4b-4281-b951-d872f2087c98
* Use an explicit boolean has_new_first_party_for_cookies insteadwtc@chromium.org2009-11-181-0/+3
| | | | | | | | | | | | of an empty, invalid URL to indicate whether the first party for cookies URL needs changing when following a redirect. R=eroman BUG=25133 TEST=none Review URL: http://codereview.chromium.org/405011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32260 0039d316-1c4b-4281-b951-d872f2087c98
* Propagate the "first party for cookies" from WebKit to the network stackwtc@chromium.org2009-11-131-4/+8
| | | | | | | | | | | | | | when we follow a redirect, because WebKit's MainResourceLoader::willSendRequest method may change the "first party for cookies" URL of the resource request. R=abarth BUG=25133 TEST=In Options menu, change cookie policy to "Accept cookies only from sites I visit" and then follow the instructions in issue 25133 comment 20. Review URL: http://codereview.chromium.org/385024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31951 0039d316-1c4b-4281-b951-d872f2087c98
* Upstreaming WebKit.gypyaar@chromium.org2009-11-121-6/+6
| | | | | | | | | | | | This mega patch contains a few simple but tightly dependent changes: 1. Deletion of webkit/api/WebKit.gyp. The file now lives in webkit.org. 2. Rename of webkit/webkit.gyp to webkit/webkit_glue.gyp. Having two webkit.gyp was a source of developer confusion. 3. Gyp dependencies are updated across chromium to point at the upstream WebKit.gyp and the renamed webkit_glue.gyp. 4. Some 200+ files include paths fixed to point to third_party/WebKit/WebKit/chromium instead of webkit/api. The later will be deleted in a subsequent patch. Review URL: http://codereview.chromium.org/387020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31749 0039d316-1c4b-4281-b951-d872f2087c98
* Enable localization of default downloaded filename.tony@chromium.org2009-11-041-7/+3
| | | | | | | | | | | | | | | Instead of localizing "download" string in net_util.cc, make a caller, download_manger, provide a localized string. BUG=25289 TEST=NetUtilTest.GetSuggestedFilename,DownloadManagerTest.TestDownloadFilename Original patch by hayato@google.com at: http://codereview.chromium.org/343014/show Review URL: http://codereview.chromium.org/367003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30971 0039d316-1c4b-4281-b951-d872f2087c98
* 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
generated by cgit v1.1 at 2025-02-01 05:47:34 +0000