Summary: | Resources are loaded from the memory cache before willSendRequest has a chance to modify the request | ||
---|---|---|---|
Product: | WebKit | Reporter: | Andy Estes <aestes> |
Component: | Page Loading | Assignee: | Andy Estes <aestes> |
Status: | ASSIGNED --- | ||
Severity: | Critical | CC: | abarth, ap, beidson, japhet, jochen |
Priority: | P2 | Keywords: | InRadar |
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All |
Description
Andy Estes
2013-03-25 16:47:28 PDT
It looks like we've added a new callback on FrameLoaderClient called willRequestResource that behaves similar to willSendRequest but is called on cached resources: <http://trac.webkit.org/changeset/135872> Come now, we definitely have at least one dupe of this already, right? Note, however, that the chromium API does not allow for modifying the request. If you want to modify the request, you should double-check that this doesn't break the loader. (In reply to comment #3) > Come now, we definitely have at least one dupe of this already, right? I couldn't find one, but maybe you can dig something up! I found <https://bugs.webkit.org/show_bug.cgi?id=56647>, which seems to be arguing in the opposite direction of what I'm proposing, and the only client I know that's encountered this issue solved it by disabling the memory cache via WebKit1 SPI. (In reply to comment #4) > Note, however, that the chromium API does not allow for modifying the request. If you want to modify the request, you should double-check that this doesn't break the loader. Thanks, that's useful to know. Apple's API does already support request modification, so the loader should support it in the existing willSendRequest code path, but I'll tread carefully. (In reply to comment #6) > (In reply to comment #4) > > Note, however, that the chromium API does not allow for modifying the request. If you want to modify the request, you should double-check that this doesn't break the loader. > > Thanks, that's useful to know. Apple's API does already support request modification, so the loader should support it in the existing willSendRequest code path, but I'll tread carefully. Sorry if that was unclear. In willSendRequest, we also allow for modifying requests, just not in willRequestResource (In reply to comment #7) > Sorry if that was unclear. In willSendRequest, we also allow for modifying requests, just not in willRequestResource Ah, that makes sense. Thanks! For now I'm just going to handle the case where the delegate returns NULL. I'm going to do that in <https://bugs.webkit.org/show_bug.cgi?id=114075>, and leave this bug open to handle the general case of request modification. |