| Comments: |
![[User Picture]](http://l-userpic.livejournal.com/54541970/2) | From: brad Thu, 5-May-2005 3:22 PM (UTC)
First Idiot! | (Link)
|
The ghetto fuck-you-browser way I know to do this is to load the new HTML with JavaScript, and have JavaScript also replace the entire body content with the new version.
And you could put the typical refresh mode in a [noscript] or document.write it out in your head if they don't have a modern browser with XMLHttpRequest.
I'll hack up a demo and put it on bradfitz.com for you to steal.
![[User Picture]](http://l-userpic.livejournal.com/41137578/353803) | From: fo0bar Thu, 5-May-2005 3:24 PM (UTC)
Re: First Idiot! | (Link)
|
What the hell do you know about making a web site?
Damn LJ newbies...
![[User Picture]](http://l-userpic.livejournal.com/54541970/2) | From: brad Thu, 5-May-2005 3:29 PM (UTC)
Re: First Idiot! | (Link)
|
Please don't suggest that I rewrite it all using XMLHttpRequest or Java or Flash or whatever. Obviously if I were willing to do that, I'd have done it already.
I could've sworn you added that after my comment. :-)
![[User Picture]](http://l-userpic.livejournal.com/9624370/1571) | From: evan Thu, 5-May-2005 3:39 PM (UTC)
Re: First Idiot! | (Link)
|
I have this same problem when I reload my LJ friends page -- all of the images people have posted reload.
You amuse the hell out of me. You don't want to use the technologies that came to the fore to deal with the exact problem they were designed to deal with. Hehehehe. Seeing as tho Moz and FF are your target platform, there is a Moz specific technology to deal with this sort of thing, but i suspect you will hate it more than XMLHttpRequest. It involves RDF.
*evil grin*
![[User Picture]](http://l-userpic.livejournal.com/5887295/515656) | From: jwz Thu, 5-May-2005 3:42 PM (UTC)
dear lazyweb, please note | (Link)
|
I'm glad I amuse the hell out of you, but the feeling is not mutual.
I thought it was obvious by now, but this is exactly the sort of comment that gets you banned. So if that was your goal, you hit it in one. *plonk*
Quoted from: http://www.jwz.org/gronk/#requirementsRequirements: - ...
- A web browser that supports HTML circa 1995. (Tables and colors, but no JavaScript, no layers, no plugins.)
Emphasis mine.
![[User Picture]](http://l-userpic.livejournal.com/6398792/1242045) | From: tkil Thu, 5-May-2005 3:47 PM (UTC)
frames and javascript? | (Link)
|
Short answer: I can't think of a way to make the one-page / one-document version work the way you want it to. And given the expirations on images vs. html, is the browser really re-loading the images [status 200] from the server, or is it getting 304s as expected, and the flicker is just the reflow of the HTML? If this is the case, I don't see how you can solve it with pure HTML, and some sort of client-side smarts is required. If you'd be ok with using javascript (and optionally frames), you can use one frame (or, as brad indicates, just javascript) to check for new content ... and only reload the main window when there is new content. (I've thought about this w.r.t. SlimServer; its web front-end has the same problem of balancing refreshes vs. flicker.)
![[User Picture]](http://l-userpic.livejournal.com/5887295/515656) | From: jwz Thu, 5-May-2005 3:51 PM (UTC)
Re: frames and javascript? | (Link)
|
It's really reloading the images, status 200.
![[User Picture]](http://l-userpic.livejournal.com/54541970/2) | From: brad Thu, 5-May-2005 3:55 PM (UTC)
| (Link)
|
that image still flickers in firefox
![[User Picture]](http://l-userpic.livejournal.com/70952415/4224) | From: sol3 Thu, 5-May-2005 3:58 PM (UTC)
| (Link)
|
It looks like firefox is still insisting on doing a get with an "If-modified since" header, even when cached. I believe Expires/Cache-Control really on affect proxies/caches, and are not necessarily obeyed by browsers. Check the access log, and see if apache is at least returning 304's for the image requests. While that doesn't solve the issue of the multiple requests, it should at least keep the images from being shot over the wire repeatedly.
The image flicker could be less from images reloading and more from page redrawing - stupid question, are you explicitly sizing images (and other elements) - in css or otherwise?
(This is from digging at my own server and its logs to try to solve a similar issue)
![[User Picture]](http://l-userpic.livejournal.com/5887295/515656) | From: jwz Thu, 5-May-2005 4:01 PM (UTC)
| (Link)
|
The server is sending 200, not 304. All the IMG tags have width/height.
![[User Picture]](http://l-userpic.livejournal.com/5887295/515656) | From: jwz Thu, 5-May-2005 4:09 PM (UTC)
Re: is the HTML dynamically driven? | (Link)
|
You can't send 304 unless the client sent If-Modified-Since -- they might really not have the image cached any more.
I managed to trick firefox 1.0.3 by using two pages, a.html and b.html, that have their refresh set to each other. the server logs show 304 for both the pages and the images in them. it doesn't work if a.html refreshes to itself, it has to be two pages.
oh, the caching also takes effect. on most of the refreshes it's just probing for the html pages, it doesn't ask about the images until the magical cache says so.
I wonder if that would work with filenames a.cgi?noop1 and a.cgi?noop2
Is AllowOverride All set for the directory in httpd.conf?
![[User Picture]](http://l-userpic.livejournal.com/5887295/515656) | From: jwz Thu, 5-May-2005 4:39 PM (UTC)
| (Link)
|
Yes, and you can tell it's working by looking at the Date and Expires headers that I pasted.
The problem is in your meta refresh tag. Most browsers interpret this as "completely invalidate all elements on the page and refresh everything." I just duplicated your test case on Safari on my local box. My only suggestion is to try this snippet of Javascript in place of your meta refresh tag:
<script language="JavaScript">
setTimeout("document.location.reload()",3000);
</script>
(adjust the 3000 to taste)
Scratch that. The reload looks like it forces cache invalidation. Try this instead.
var pUrl = document.location.href;
document.location.href = pUrl.substring(0,pUrl.indexOf("?"))+"?"+new Date().getTime();
you're like the rat that keeps shocking itself, only you don't even get anything out of it.
It doesn't happen in PointCast.
/runs like hell
From: cloudblur Fri, 6-May-2005 12:07 AM (UTC)
Cache settings in your browser | (Link)
|
What are you cache settings in your browser? Firefox, if set to "Check every time" has the behavior of not caching images and not doing If-Modified-Since requests that normally result in 304.
It might be your cache settings, what about privoxy maybe stripping things?
Here’s a funny: where do you change that setting in Firefox? I just looked through all of the entire Preferences dialog and can’t find it anywhere.
I was trying to find out what the specified behavior ought to be, but I then realized that this is a Netscape invention, so the entirety of the specification is in this document. It's a bit underspecified. That HTTP header, in turn, tells the browser to go reload (refresh) this document after 1 second has elapsed.
It doesn't really say whether the browser should treat it as a forced reload, or what to do about getting images, etc from cache. I'm also willing to bet there are pages that rely on the current behavior.
Also a fix for bug 290090 might fix this behavior, not sure.
Not sure if your requirements also exclude javascript, if not, what would happen if you used a refresh(false) on a page that is expired? Docs say passing false will not reload it form the server, I wonder if this is true even if the page is expired. Also, I have seen many suggestions using ping pong between 2 html pages etc. I wonder if explicitly reloading the same url might produce the same effect, i.e. what would this do: <META HTTP-EQUIV="refresh" CONTENT="5; URL= http://__link to the same page__"> | |