Opened 11 years ago
Closed 11 years ago
#290 closed design (fixed)
Motivate one-year limit for Expires
Reported by: | mnot@… | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 16 |
Component: | p6-cache | Severity: | Active WG Document |
Keywords: | Cc: |
Description
In p6 3.3,
A server SHOULD NOT send Expires dates more than one year in the future.
What's the motivation for this SHOULD NOT? We should explain or remove it.
Change History (5)
comment:1 Changed 11 years ago by mnot@…
- Milestone changed from unassigned to 16
comment:2 Changed 11 years ago by mnot@…
comment:3 Changed 11 years ago by mnot@…
- Resolution set to incorporated
- Status changed from new to closed
comment:4 Changed 11 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:5 Changed 11 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
Note: See
TracTickets for help on using
tickets.
Proposal:
Remove the requirement in p6 3.3 and replace it with:
""" Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use of 32-bit integers for time values), and most caches will evict a response far sooner than that. Therefore, senders ought not produce them. """