* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #169 (closed design: fixed)

Opened 6 years ago

Last modified 5 years ago

private and no-cache CC directives with headers

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: normal Milestone: 08
Component: p6-cache Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/4A1C2426.6010205@qbik.com

Description

  1. private directive with headers.

It states that these headers then are all that is private, and these must not be stored. However it does not state what to do when you get a subsequent request for that URI that would match. Does this mean that the stored response must be revalidated with the server, or is it appropriate to send the stored response (if still fresh) to the client without those headers?

  1. no-cache.

It's not clear to me what the point of revalidating an entire entry vs just revalidating header fields. Especially when you consider that a conditional request will revalidate both or either. So I can't see any point in having headers specified in a no-cache response directive. Unless it's intended that failure to revalidate just headers could still result in the entry being served, but that in that case those headers would need to be omitted?

Are these implemented and/or useful? Is it worth deprecating them (while still supporting them syntactically)?

Change History

comment:1 Changed 5 years ago by mnot@pobox.com

  • Owner set to mnot@pobox.com
  • Priority set to normal

Proposal: add note that this isn't widely implemented.

comment:2 Changed 5 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 08

comment:3 Changed 5 years ago by mnot@pobox.com

From [710]:

note that qualified forms of cc: private and no-cache aren't often implemented (see #169)

comment:4 Changed 5 years ago by mnot@pobox.com

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