[Webkit-unassigned] [Bug 48483] Get rid of ResourceRequestBase::m_targetType

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 30 09:52:18 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=48483





--- Comment #10 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2010-11-30 09:52:17 PST ---
Originally, TargetType was added to chromium/ResourceRequest.h (not ResourceRequestBase.h) with the intention of it being Chromium specific.

Chromium uses TargetType information for several purposes:

1- To prioritize network requests.

2- To determine requests that could be subject to being treated as a download.

3- To implement an optional security filter, where by images loaded with a bad certificate are replaced with a placeholder image.  This feature is not enabled by default.

4- To identify prefetch requests, which are loaded with special policy.

5- To identify cases where an external protocol handler may be loaded via ShellExecute (i.e., only if the target type is a frame).

6- As part of identifying main frame requests that correspond to a cross-process tab navigation.

7- Probably for some other things that I didn't turn up with a quick grep.

As you can see TargetType is more than just a priority field.

I believe that fixing bug 49113 would make it so that we no longer need this field for PLATFORM(CHROMIUM).  The additional meta data required by Chromium could be captured by Chromium within the willSendRequest callback and it could tag that information on the ResourceRequest for its use.

While I agree the above does not address the "laying violation" concerns, it at least isolates the issue, which is an improvement.

A good first step may be to move TargetType back to chromium/ResourceRequest.h, and copy it to the Blackberry's version of ResourceRequest.h as well.  That will help avoid extra uses of this field from cropping up.

Maybe this is for a different discussion, but long-term, I believe we need a layer between ResourceLoader and ResourceHandle that abstracts the concept of "network stack", providing the right layer for indirection.  This is the layer where appcache, blobs, and other concepts that CFNetwork doesn't understand would live.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list