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

From: Roberto Polli <[email-masked]>
Date: Mon, 5 Aug 2019 12:38:05 +0200

Hi @all,

While reading the Retry-After specs I was guessing...

if we had to reboot the retry-after header, would we use the HTTP-date
 or the unix-timestamp syntax?
iiuc the HTTP-date format was inherited from RFC 822 with the goal of
being human-readable.

Thanks for your feedback,
and have a nice day,
R.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 6 Aug 2019 00:01:40 +1200

>  or the unix-timestamp syntax?

Why re-design it at all?

If anything reduce it to just the delay-seconds field value. That is
compatible with any time locale.

Amos

---

From: Roberto Polli <[email-masked]>
Date: Mon, 5 Aug 2019 14:28:58 +0200

Hi Amos,

and thanks for your reply!

> >  or the unix-timestamp syntax?
To clarify, I don't want to redesign Retry-After :)
Instead I'm working on a new I-D to standardize `RateLimit-*` headers:

- https://ioggstream.github.io/draft-polli-ratelimit-headers/draft-polli-ratelimit-headers.html

and I'm investigating the relations with `Retry-After`:

- https://github.com/ioggstream/draft-polli-ratelimit-headers/issues/15#issuecomment-518199305

> compatible with any time locale.

Agree. You can see:

- https://ioggstream.github.io/draft-polli-ratelimit-headers/draft-polli-ratelimit-headers.html#rfc.section.3.3

If you are interested in the I-D, your suggestions and contributions
will be precious and welcome.

Have a nice day,
R

---

From: Felipe Gasper <[email-masked]>
Date: Mon, 5 Aug 2019 11:06:11 -0400

> On Aug 5, 2019, at 6:38 AM, Roberto Polli <[email-masked]> wrote:
> 
> Hi @all,
> 

I would think RFC 3339 would be the preferred format.

-Felipe Gasper
Mississauga, Ontario

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 5 Aug 2019 14:25:40 +0200

delay in whatever time unit needed is a good Idea, totally agree.
compatible to basically anything without needing to care for DST, leap
days/seconds or whatever, just a stupidly simple second counter.

---

From: Wenbo Zhu <[email-masked]>
Date: Tue, 6 Aug 2019 11:51:44 -0700

> days/seconds or whatever, just a stupidly simple second counter.
And it needs to be a float type (32-bit) to support sub-second intervals.
(also my earlier question on "Prefer: timeout= ...."  ... )

---

From: Philipp Junghannß <[email-masked]>
Date: Tue, 6 Aug 2019 20:59:28 +0200

interesting Idea also the advantage over the unixtime is that you dont get
to deal with the Year 2038 problem later if we are still having to deal
with systems too old/weird/whatever for 64 bit times

with one very small exception. a system which is unaware of the fault doing
a request shortly before the overflow with the retry stated for after the
overflow, but aside from that relatively short edge case nobody is going to
care whether the server clock is on 1901 or whatever unless we are dealing
with stuff that needs the absolute time (which this is not)

Am Di., 6. Aug. 2019 um 20:51 Uhr schrieb Wenbo Zhu <[email-masked]>:

>
>
> On Mon, Aug 5, 2019 at 11:59 PM Philipp Junghannß <
> [email-masked]> wrote:
>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 8 Aug 2019 00:29:53 +1200

On 7/08/19 6:51 am, Wenbo Zhu wrote:
> 
> On Mon, Aug 5, 2019 at 11:59 PM Philipp Junghannß wrote:
> 
>     compatible to basically anything without needing to care for DST,
>     leap days/seconds or whatever, just a stupidly simple second counter.
> 
> 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.

Amos

---

From: Roberto Polli <[email-masked]>
Date: Wed, 7 Aug 2019 16:16:14 +0200

Thanks @all for your replies!

Il giorno mar 6 ago 2019 alle ore 21:03 Philipp Junghannß
<[email-masked]> 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 <[email-masked]>:
>> Wenbo Zhu <[email-masked]>:
>> And it needs to be a float type (32-bit) to support sub-second intervals. (also my earlier question on "Prefer: timeout= ...."  ... )
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?

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.

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

---

From: Wenbo Zhu <[email-masked]>
Date: Wed, 7 Aug 2019 09:56:49 -0700

> @wenboz, can you provide some use case where subsecond precision
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
Interesting .. and I will certainly have a closer look.

Thanks,
Wenbo