DESCRIPTION: It seems that the referer HTTP header field is no longer sent for images (or sent correctly). I haven't verified this, but this URL is known to require that the referer be the page containing the image, or it sends the "Incomplete Image Request" image instead. STEPS TO REPRODUCE: * load http://www.intellicast.com/LocalWeather/World/UnitedStates/Northeast/Massachusetts/Boston/Radar/ ACTUAL RESULTS: * "Incomplete Image Request Received" image EXPECTED RESULTS: * radar image DOES NOT WORK CORRECTLY ON: * Linux, mozilla, 2000-04-23-09-M16

Yep, that does seem to be what's happening. mozilla "GET / HTTP/1.1" 200 502 "" "Mozilla/5.0 (Windows; U; Win98; en-US; m16) Gecko/20000423" "GET /icons/logo.gif HTTP/1.1" 200 3905 "" "Mozilla/5.0 (Windows; U; Win98; en- US; m16) Gecko/20000423" internet explorer "GET / HTTP/1.1" 200 502 "" "Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)" "GET /icons/logo.gif HTTP/1.1" 200 3905 "http://jesser.dhs.org/" "Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)" proof that nobody knows whether it's referrer or referer: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 (webster says 2 r's) Once this is fixed, maybe look at bug 32359 again.

this turns out to be messier than I had envisioned. The recent docshell/webshell changes seems to have left out setting the defaultLoadChannel which makes getting the referrer difficult (in ImageAsyncNetContext::GetURL) rpotts when you get a chance to cleanup that code, this will work fine. deferring till M17.

wfm 2000 060408 win 98 (note that os is already set to linux)

Yup, I think somebody fixed this. Marking WORKSFORME.

marking verified. the image loads now. also I believe there was a duplicate of this bug at some point. tested on linux 2000092810 MN6 comm bits.