Re: The Refresh header is still with us

On 2019-03-12 12:56 p.m., Amos Jeffries wrote:
> 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.

if it's not ready yet:

"""
GET /next.php?marker=... HTTP/1.1
Host: ...

HTTP/1.1 200 OK
Refresh: 5
Content-Type: text/html

"""

if it's ready:

"""
GET /next.php?marker=... HTTP/1.1
Host: ...

HTTP/1.1 200 OK
Content-Type: text/html

<html><head>...</head><body><iframe 
src="/next.php?marker=..."></iframe><article>post 
here</article></body></html>
"""

(look, no JS!)

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

See above. HTML requires that iframes make separate document contexts, 
whereas in my ideal world they'd be part of the same document context.

(This is definitely the wrong mailing list tho. Just trying to 
demonstrate my use-case.)

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

Refresh instructs the reader to re-fetch after N seconds. Dynamically 
adjusting the fetch interval allows to dynamically control flood, 
assuming all clients are well-behaved.

This would do wonders for anyone using RSS feeds, as their servers would 
no longer being hammered every 30 minutes with millions of feed requests.

Cache-Control is cool and all but it simply prevents the reader from 
fetching it again if its rate is set too fast. And even then, most 
readers don't implement cache, because they expect the feeds to be mutable.

>
> AYJ
>

Received on Tuesday, 12 March 2019 18:39:19 UTC