Re: The Refresh header is still with us

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
meta-refresh.


> 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.

AYJ

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