23 years to ruin one line of the HTTP specification
Let's compare an excerpt from RFC 2616 section 13.3.3 to the equivalent one in RFC 9110 section 8.8.2.
RFC 2616, from 1999, has the following to say:
- The validator is being compared by an intermediate cache to the validator stored in its cache entry for the entity, and
- That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
- The presented Last-Modified time is at least 60 seconds before the Date value.
A bit wordy, like most RFCs, but it is defining a well-described algorithm. it has a specific recommendation of an exact time interval to use to account for various clock issues, such as Date being generated after the body of the document, introducing some offset.
RFC 9110, on the other hand, has this to say (emphasis mine):
- The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation, and
- That cache entry includes a Date value which is at least one second after the Last-Modified value and the cache has reason to believe that they were generated by the same clock or that there is enough difference between the Last-Modified and Date values to make clock synchronization issues unlikely.
Reason to believe they were generated by the same clock? What is that supposed to mean? Am I supposed to do research into the quality of Date header generation by various server software and sniff the Server field, and judge them on that? Maybe I should profile them off how long it takes them to generate a response?
The second half of this sentence seems to realize what it is asking is impractical, so it defers to the old guidance of using some buffer period to account for possible issues, however this time without any precise recommendation. Am I meant to believe the needed grace period is less than it was, due to two decades of improvements to hardware and software? Or perhaps the opposite, 60 seconds was not considered enough to eliminate the niche possibility of some combination of compounding errors?
If there's anything to learn from this, its that its important to keep the purpose of any technical writing you author in mind, whether that's a specification for a major internet protocol, or the documentation of a hobby project. Do you want to tell people your best guidance for how to do things, or do you want to vaguely gesture at the concept of nuance to ensure you never say anything that could be considered incorrect?
You can follow this blog via its RSS feed or by searching for @[email protected] on your Mastodon/ActivityPub instance.