[Webkit-unassigned] [Bug 80713] Add new methods to FrameLoaderClient so different WebKit ports can customize the ResourceRequest when it is created.

[bugzilla-daemon at webkit.org]

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





--- Comment #26 from Joe Mason <jmason at rim.com>  2012-03-12 12:49:15 PST ---
(In reply to comment #23)
> It still feels entirely wrong to me to add two new callbacks when there is already one designed largely for the same purpose.

Well, it seems to me that if the platform is allowed to make customizations to the request, it should be allowed to do it before dispatchDecidePolicyForXXX.  Moving willSendRequest before that doesn't seem right, since until dispatchDecidePolicyForXXX returns PolicyUse, it's not guaranteed the request will be sent.

And the name of "willSendRequest" doesn't tell me that it's intended for altering the request - it tells me that it's intended to be a notification that a request is about to be sent.  The fact that it has a non-const parameter which can be altered isn't clear from the name.

It seems reasonable to me to have two entry points to customize the request, one before dispatchDecidePolicy and one only for requests that will actually be sent.  For instance, the platform might want to do one set of customizations that applies both to PolicyUse and PolicyDownload, and another that applies only to PolicyUse.

I don't like the name of the two new methods, though.  First, they can be used to update existing fields as well as add new fields, so "addExtraFields" doesn't seem right.  Second, I think we should have just one new method, with an enum parameter saying whether it's a main resource of subresource request.  I suggest calling it "customizeRequest", or to be more explicit about timing, "customizeRequestBeforePolicyCheck".

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