Opened 7 years ago

Closed 7 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 7 years ago by mnot@…

Proposal for Private:

... That is, a shared cache MUST NOT store the specified field-names(s), whereas it MAY store the remainder of the response message.

to

... That is, a shared cache MUST NOT store the specified field-names(s), whereas it MAY store the remainder of the response message (and subsequently reuse it).

I'm less clear about the right thing to do for the no-cache form. It might be good to consider deprecating it.

comment:2 Changed 7 years ago by mnot@…

  • Milestone changed from unassigned to 19
  • Resolution set to incorporated
  • Status changed from new to closed

comment:3 Changed 7 years ago by julian.reschke@…

See [1563]

comment:4 Changed 7 years ago by julian.reschke@…

From [1564]:

Note changes for [1563] (see #337)

comment:5 Changed 7 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:6 Changed 7 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.