On managing memory leakage with assignment to IMG src in UIWebView

The issue with leaking memory due to dynamic image updates in 
 UIWebView hosted pages can be fixed with a solution I call 
 
   The "humpty dumpty" solution !
 
 The problem can be particularly severe on the 128MB iPhone 3G 
 for long running charting applications.
 
 To summarize, the statement for any IMG being dynamically updated is -
 
   img.src = url;   // this url is a dynamic image file generator
 
 Now most browsers will not retrieve the url more than twice ( why twice
 I do not know, it is repeatable on the current versions of Safari and Chrome ).
 
 So we add something to force the browser to call the URL -
 
   img.src = url + ?now              // seconds since epoch will do
   img.src = url + ?incarnation++    // a incrementing incarnation
 
 Now webkit starts leaking memory by storing all the urls
 that are thus generated, in the charting application I am issuing 
 these as rapidly as once a second.
 
 So now lets just simplify this to 
 
   if img.src contains 'humpty'
     img.src = url + ?incarnation=dumpty
   else
     img.src = url + ?incarnation=humpty
 
 !!!
 
 This should resolve the issue with storing a new URL every second,
 but it does not work. This is because webkit ( and any browser )
 will simply go to cache for humpty and dumpty after the first
 2 origin server fetches.
 
 To fix this, add HTTP headers to the response from the image handler URL - 
 
   Expires: 0
   Pragma: no-cache
   Cache-Control: no-store, no-cache, must-revalidate
 
 This is the minimal set which is supposed to work across all the different
 proxy servers which may lie on the path, though if there is no
 proxy server just 
 
   Cache-control: no-store
 
 will work fine with webkit.