undefined | Better HN

0 pointse12e3y ago0 comments

> The HTTP 1.0 spec already had a solution for two machines with different ideas of the current date.

I can't recall noticing this, and can't seem to find anything about it in[1] - could you elaborate?

[1] https://www.w3.org/Protocols/HTTP/1.0/spec.html#Date

0 comments

You’ve found it, or very nearly. The very next section is Expires:

> The format is an absolute date and time as defined by HTTP-date in Section 3.3.

The implication is subtle but critical. When the server sends a Date header and an Expires header, you don’t expire the content when the local time exceeds the Expires Header. You expire it at

   LocalTime + (Expires - Date)

That covers not only time zones but also clock drift. When the client is sending data such as a POST, it also sends a Date header. That can account for time zones, clock drift, and to an extent network latency. When you’re legally bound to establish the order of events in a distributed system someone has to be the source of truth, and even when you’re not it’s still good to have for your own purposes. The system of record is the only thing that is running on the same clock as the system of record, so it is the most sensible source of truth.

So when a client sends you a buffer full of dated events, you can (and should) consider the timestamps in the POST body as relative to the Date header, not your local system time. Otherwise someone running on brown power or old school power saving mode will screw up all of the timelines in your data.

masklinn3y ago

> You expire it at LocalTime + (Expires - Date)

Which makes for a wonky mess, and I guess is why Cache-Control did away with the entire thing and just tells you how long the response is fresh.

hinkley3y ago

Not as wonky as you'd think, and 60 minutes means something much different than 12:15. Which can be good and it can be bad, but many of my experiences with TTLs have not been pleasant. 60 minutes, as typically implemented, means some user out there has data that is 1:58 stale and he's yelling at your boss on the phone who is now trying to figure out if he should be passing the favor along.

See also ETags which stop trying to be clever about dates and instead be clever about the contents of the message.

Why I like the Date header is that it works well with REST endpoints that care about time but for whom caching is either not a good idea or is orthogonal.

masklinn3y ago

> Not as wonky as you'd think, and 60 minutes means something much different than 12:15.

The expression you’ve posted is literally a complicated way of writing 60mn, and you specifically wrote that it should not be interpreted as 12:15.

> See also ETags which stop trying to be clever about dates

Etags have unrelated role and semantics. Etags go with last-update, which doesn’t suffer from anywhere near as much from drift because it’s checked by the server, which emitted it.

j / k navigate · click thread line to collapse

0 comments

hinkley3y ago

You’ve found it, or very nearly. The very next section is Expires:

> The format is an absolute date and time as defined by HTTP-date in Section 3.3.

The implication is subtle but critical. When the server sends a Date header and an Expires header, you don’t expire the content when the local time exceeds the Expires Header. You expire it at

   LocalTime + (Expires - Date)

masklinn3y ago

> You expire it at LocalTime + (Expires - Date)

Which makes for a wonky mess, and I guess is why Cache-Control did away with the entire thing and just tells you how long the response is fresh.

hinkley3y ago

See also ETags which stop trying to be clever about dates and instead be clever about the contents of the message.

Why I like the Date header is that it works well with REST endpoints that care about time but for whom caching is either not a good idea or is orthogonal.

masklinn3y ago

> Not as wonky as you'd think, and 60 minutes means something much different than 12:15.

The expression you’ve posted is literally a complicated way of writing 60mn, and you specifically wrote that it should not be interpreted as 12:15.

> See also ETags which stop trying to be clever about dates

Etags have unrelated role and semantics. Etags go with last-update, which doesn’t suffer from anywhere near as much from drift because it’s checked by the server, which emitted it.

j / k navigate · click thread line to collapse