Opened 10 years ago
Closed 10 years ago
#337 closed design (fixed)
Field names in cache-control header arguments
Reported by: | mnot@… | Owned by: | draft-ietf-httpbis-p6-cache@… |
---|---|---|---|
Priority: | normal | Milestone: | 19 |
Component: | p6-cache | Severity: | Active WG Document |
Keywords: | Cc: |
Description
The discussion of optional field-names in "private" and "no-cache" is vague about whether the cache MAY or MUST revalidate when handling a subsequent request for that resource. That is, if another request for the resource comes in, and the cached response is still fresh, is the cache allowed to return it, minus the forbidden headers, or is it required to revalidate, and merge in new values of those headers from the 304 response?)
Change History (6)
comment:1 Changed 10 years ago by mnot@…
comment:2 Changed 10 years ago by mnot@…
- Milestone changed from unassigned to 19
- Resolution set to incorporated
- Status changed from new to closed
comment:3 Changed 10 years ago by julian.reschke@…
See [1563]
comment:4 Changed 10 years ago by julian.reschke@…
comment:5 Changed 10 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:6 Changed 10 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
Note: See
TracTickets for help on using
tickets.
Proposal for Private:
to
I'm less clear about the right thing to do for the no-cache form. It might be good to consider deprecating it.