HTTP Downloads and Caching

140 views
Skip to first unread message

Cameron Braid

unread,
Feb 13, 2007, 2:54:37 AM2/13/07
to Firebug
First of all, I want to say congratulations on FireBug.. I've been
using it since 0.4 and it is an invaluable tool.

In the console and net view, when a URL is downloaded with status '304
not modified' there is no indication that this is the case. This
makes it hard to determine if the url is cached. The status could
show up the same way a 404 error is reported - change the color of the
url and have the status in brackets. This could probably apply to all
urls that don't result in status=200.

It also appears that firebug isn't reporting on the browser cache the
same way as other extensions.. Now, this may not be a bug with
firebug, but the two other extensions that I have been using seem
consistent.

I have looked at the headers from the "Live HTTP Headers" extension
and the "Tamper Data" extension, and they both report that the urls in
question havn't been downloaded.

For example, I do a shift-refresh, and see my 92k javascript resource
in both "Tamper Data" and "Live HTTP Headers" as being downloaded. It
also also shows up in firebug, this is good. Then I do a normal url
get (Alt-D Enter) and "Tamper Data" shows it as staus=pending, which
means the browser hasn't even requested the url from the server.
"Live HTTP Headers" doesn't show anything at all for it, indicating
the same. Firebug shows it as in the Net tab as being downloaded and
taking 2 seconds.

Cheers,

Cameron

robertivanc

unread,
Feb 15, 2007, 3:11:40 PM2/15/07
to Firebug
yep, I've noticed this as well, and it took me some time to figure out
that this is what is happening.
It's quite deceiving as it looks that firefox keeps requesting these
files where in fact it just loads them from the cache.

Robert

Adam

unread,
Feb 15, 2007, 4:38:58 PM2/15/07
to Firebug
Actually, what it means is that the on-modify-request hook has been
fired, but not the on-examine-response hook.

This happens because examination of the cache, and previous response
headers happens after the first hook is called. This is also why you
can't tamper with the cache control headers.

LiveHTTPHeaders doesn't show the requests at all, because that
extension (which tamperdata was partially based on) only monitors the
on-examine-response hook.

Adam

Reply all
Reply to author
Forward
0 new messages