Re: The Refresh header is still with us

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

I was just trying to keep it short for the email/because I'm lazy.

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

This doesn't even work. Refresh is much better supported in browsers. 
And technically I do need a dummy response body actually (see below, but 
this is off-topic).

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

I'm talking about how you can't style an iframe from outside the iframe. 
So you need to bloat up the response with garbage, because browsers. 
Anyway, off-topic.

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

And this lets me specify the feed's refresh interval how? It is my 
understanding that this still relies heavily on the reader having a set 
refresh interval like 30 minutes or something, whereas with Refresh 
header I'm actively telling it how often I want it to check for updates, 
with the ability to adjust it as needed and basically do all the request 
scheduling on the server, because this is the next best thing beside 
just going peer-to-peer. (Note that I do always want/need to provide a 
body for the specific case of RSS feeds.)

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

Definitely not with properly-configured TLS. (and I have a long list of 
complaints/stuff about how we could be doing this better, but it 
involves a new protocol.)

>
>
> AYJ
>

PS: I strongly agree that Refresh should NEVER be used for redirects, 
ever. It's called Refresh, not Redirect.

Additionally, when I say "properly-configured TLS", I'm referring to 
something that provides end-to-end security. As an example, signed 
messages are end-to-end secured. They're not necessarily end-to-end 
encrypted, but they're still integrity protected, which is a form of 
security. This is different from how modern CDNs do it where they just 
take your signed and encrypted message, decrypt (and sometimes, but not 
always, validate) it, and then slap their own stuff on it. And sometimes 
they don't even bother encrypting your end of it!

Received on Wednesday, 13 March 2019 02:09:49 UTC