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@…

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 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@…

From [1564]:

Note changes for [1563] (see #337)

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.