User-agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
Rob Keniger wrote:
On Aug 23, 2007, at 10:40 AM, Rudi Sherry wrote:
You can create a new NSURLProtocol; this is pretty low-level and
should be asked if it can handle any request. You're given some sort
of Protocol client to which you hand the bytes, and you are told when
to start and stop.
There is a great sample project from Apple which shows how to do this:
The OP didn't say why he wants to control the resource loading, but I
will add a cautionary note here just in case he's doing something tricky.
If you are doing this so that you can return different data at different
times for the same resource URL in the page, then you have a problem.
(For example, your page contains the element <img href="MyImage.gif" />
and when you see the "MyImage.gif" URL you look at some data and decide
what picture you should really display, and it can be a different
picture every time.) The problem is not in the currently shipping
WebKit, but it is in the nightly builds and, I assume, will be in the
WebKit that supports Safari 3 and ships with Leopard. What happens is
that when page resources are loaded, their data is cached, and the
cached data is keyed by the original URL. This means that whatever data
you return the first time you intercept that URL will be used
delegate will only be called the first time, and the data will be read
from cache after that.
I ran across this when my resources were all file:/// URLs, and it also
occurred when I switched everything to use my own custom protocol. My
protocol loader only got called the first time, but not subsequently for
the same original resource URL. It also did not seem to matter that I
specified no caching in my NSURLResponse that I used to return the data.
It was cached anyway.
If this doesn't affect you, I would still suggest that you download the
WebKit sources, build the framework, and test your app against it.
Things have been tightened up in this area. I assume this was done to
address security holes. The result is a difference in behavior between
the current and newer WebKit versions.
Do not post admin requests to the list. They will be ignored.
Webkitsdk-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden