Re: The Refresh header is still with us

On 13/03/19 7:38 am, Soni L. wrote:
> 
> 
> 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:

... caches will still be producing the previous 200 response payload for
up to _68 years_ due to lack of expiry info.


> 
> """
> 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!)
> 

Compare that to these responses using only the existing RFC723x mechanisms:

If it's not ready yet:

"
 HTTP/1.1 307 Temporary Redirect
 Date: ...
 Location: /next.php?marker=...
 Retry-After: 5
 Cache-Control: max-age=5
"

when it is ready:

"
 HTTP/1.1 200 OK
 Content-Type: text/html
 Content-Length: xxxx

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



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


AIUI, sending data in the Refresh header is supposed to be equivalent to
sending the same value in a meta-refresh of HTML. Only send the
meta-refresh in the "not ready" responses.

Since the HTML form is much more well-known and widely used it seems to
me that the better approach is from the direction of optimizing the HTML
syntax and formally removing the overlapping HTTP part.



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

I understand. See my counter examples above which use only mechanisms
from RFC 723x.

The fetch loop is provided by the 307 status code, the delay by the
Retry-After header, and the URL by the Location header (if any).


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

The middleware does though, and the reader requests go through those
just like everything else.


AYJ

Received on Wednesday, 13 March 2019 01:40:06 UTC