W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: The Refresh header is still with us

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 13 Mar 2019 04:56:01 +1300
To: ietf-http-wg@w3.org
Message-ID: <f380a757-c161-d289-268a-3d00e8180f4e@treenet.co.nz>
On 12/03/19 10:22 pm, Soni L. wrote:
> On 2019-03-12 6:19 a.m., Daniel Stenberg wrote:
>> On Mon, 11 Mar 2019, Soni L. wrote:
>>> I do use Refresh and (deeply-nested) iframes for JS-less webapps. Not
>>> sure what the alternative is here, if any. But they're not redirects.
>> So what exactly do you expect this header to do? Refresh the entire
>> page even when just a sub resource response gets it? Is what what it
>> happens? Is that working cross-browser?
>> And why use a HTTP header for this, can't you just use a meta tag
>> since you are doing a web page after all? It seems like an odd layer
>> mix to me.
> I expect it to refresh a single empty iframe. Once it's no longer empty
> it stops refreshing.

That would make it only valid on 204 responses. There is no such
restriction in the WHATWG specs and usage of meta-refresh / Refresh
seems to be to *replace* iframe contents.

> It would be nicer if I could embed HTML snippets into pages, instead of
> full documents, and still get Refresh capabilities. But anyway.

That would be meta-refresh in HTML, XHTML or similar in JavaScript.

The use-case for Refresh seems to me to be in non-dynamic content types
(eg image objects) where the data layer does not have a way to add the

> Oh, I also use Refresh for the odd RSS/Atom feed. Not sure if any feed
> readers actually care about rate-limiting themselves following the
> server's lead tho.

IMO, that would be better done with
Cache-Control:must-revalidate,max-age=N and/or Expires header. No need
to change the feed URL, just to trigger a re-fetch every N seconds.

Received on Tuesday, 12 March 2019 15:56:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 12 March 2019 15:56:46 UTC