Re: [OT] use http-equiv to refresh the page

[fliptop]

On Tue, 5 Nov 2002 at 22:52, Chris Shiflett opined:

[snip]
CS:The W3C's stance on refresh is the same for the header as well as the 
CS:meta tag: they did not originally intend for it to be used to specify a 
CS:*different* URL as a rudimentary method of redirection. They meant it to 
CS:be used to refresh the current resource only. However, this rogue 
CS:practice of redirection is quite common with both the header and the 
CS:meta tag and is very well supported by browsers. In fact, I am not aware 
CS:of any Web client that supports refresh but also limits the URL to the 
CS:current resource only.

i was bitten by this assumption recently.  case in point:

i needed to develop a way to display several images as a slideshow using
plain html files.  i would glob the images, and in each html file i
inserted a meta refresh that would load the next image in the series after
a 7 second delay.  since the html files were eventually going to be burned
to a cd, i had to point to each new file as such:

meta http-equiv=refresh content=7;file02.html

because i cannot always assume to know the user's cd-rom drive
designation.  this worked fine in netscape and mozilla, but did not work
at all in internet explorer versions previous to 5.5.  in older versions
of ie, it simply refreshed the current page after the 7 second delay, no
matter what was put after the semicolon in the content attribute.  so i
had to include instructions for the users that if they used internet
explorer, they must upgrade to at least version 5.5 for the slideshow to
work.  of course, i had tested the app on ie 5.5, so i didn't discover
this myself until a user contact me and complained the slideshow wasn't
working.

and you'd be surprised how many old versions of ie are being used out 
there.

RE: [OT] use http-equiv to refresh the page

[Alessandro Forghieri]

Greetings.

[...]
 [snip]
 CS:The W3C's stance on refresh is the same for the header as 
 well as the 
 CS:meta tag: they did not originally intend for it to be used 
 to specify a 
 CS:*different* URL as a rudimentary method of redirection. 
[...]
 i was bitten by this assumption recently.  case in point:
 
 i needed to develop a way to display several images as a 
 slideshow using
 plain html files.
[..horror story clipped]

But, in fact, redirects - either implicit or explicit - have many ways of
biting the unwary (and curiously, or perhaps not, IE always a key role).

Consider MS KB Article Q160013:

If a CGI application returns a MIME Type that is unknown or not associated
to Internet Explorer internally, Internet Explorer makes two POST requests
to the server.

What this means is that (for instance), sending a PDF file as the result of
a POST request
may cause the following sequence of events:

1) the file is downloaded
2) it is removed from the disk cache as the second POST request goes out
3) Acroread is launched and then says No such file.

this bug is active on many, many versions of IE. It happens if you either
send the file directly OR issue a redirect. 

The only workaround I could find was a meta-http-refresh. And then I found
out that using '0' as a refresh time won't work on Mozilla (who tries to
refressh the *current* page every 0 seconds and gets stuck in a loop- not
nice).

So what's a poor programmer to do, caught between standards and arguably
buggy browsers?

Cheers,
alf

P.S. Anybody knows of a better solution to Q160013, I'd like very much to
hear about it...TIA.