Re: Retry-After in UNIX Timestamp instead of HTTP-Date

On Wed, Aug 7, 2019 at 7:16 AM Roberto Polli <robipolli@gmail.com> wrote:

> Thanks @all for your replies!
>
> Il giorno mar 6 ago 2019 alle ore 21:03 Philipp Junghannß
> <teamhydro55555@gmail.com> ha scritto:
> >>> delay in whatever time unit needed is a good Idea,
> >>> [..] without needing to care for DST, leap days/seconds or whatever,
> Agree.
>
> > ... the advantage over the unixtime is that you dont get to deal with
> the Year 2038 problem
> Agree.
>
> Am Mo., 5. Aug. 2019 um 14:06 Uhr schrieb Amos Jeffries <
> squid3@treenet.co.nz>:
> >> Wenbo Zhu <wenboz@google.com>:
> >> And it needs to be a float type (32-bit) to support sub-second
> intervals. (also my earlier question on "Prefer: timeout= ...."  ... )
> >Is it really worth telling a client to re-try in less than a second?
> > At those timescales the server can just queue the request and answer
> > when it can.
> I agree with Amos about subsecond precision, as we have network and
> processing
> latency and clock skew.
>
> @wenboz, can you provide some use case where subsecond precision
> can be effectively used?
>
When HTTP is used for server-to-server communication, 1s is a very long
interval. Also, the retried request may not land on the same server
(process) due to load balancing etc so the client retry wait time has
nothing to do with the expected wait time for the server to "recover" (if
this is one of the assumptions).


> As I wrote in
> https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0201.html
> I'm writing an I-D on RateLimit headers and I'm investigating
> the relations between those headers and Retry-After.
>
Interesting .. and I will certainly have a closer look.

Thanks,
Wenbo


> Thanks for your feedback
> and have a nice day,
> R:
>