Tim wrote:
It is curious that we loop two times over ClientQueue though. Probably because the function is called every x received bytes, right?
a_Cache_process_dbuf calls Cache_process_queue once for each packet and once when it's done (IOClose).
Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... Found (id=1). HTTP warning: unhandled MIME type: "text/html; charset=iso-8859-1" Looping over ClientQueue... Looking for http://puppyisos.org/miniicons/kfm_home.png... Looking for http://puppyisos.org/miniicons/ark.png... Found (id=1). Removing client (id=1)
We should add support for charsets within MIME types anytime. As far as I know, Dillo only depends on meta-tags when deciding which encoding to go with. This notation is officially approved, see: http://www.w3.org/International/tutorials/tutorial-char-enc/#Slide0270
Charsets in MIME types are supported. It's probably complaining because it expected an image/png and got the text/html; charset=iso-8859-1 401 Auth page which can't be displayed as an image.
PS: Having applied the patch, the iterations of the ClientQueue loop will now stop after the URL has matched. Previously, the iteration for the same entry item was then repeated again (if AbortEntry is true). Is there a reason for keeping it as-is?
In case multiple clients were waiting for this data. Now I _am_ getting the crash. Maybe I accidentally typed in the main page instead. Don't think I did, but...whatever...anyway... in Cache_auth_callback(), a_Nav_reload(data->bw) does not sound at all like what we want for images on a page. We'd want something more along the lines of Cache_entry_remove() on the image and a_Nav_repush() on the page, but I think in either case that would remove clients for other images while we're trying to get their data, causing...what we're seeing. (Is dillo turning into a snarled knot?) If the last image comes in while there's no client, I wouldn't know what bw to repush.