W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: #337: Field names in cache-control header arguments

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Thu, 16 Feb 2012 08:37:15 +0100
Message-ID: <1329377835.22776.29.camel@home.hno.se>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
mån 2012-02-13 klockan 15:56 +1100 skrev Mark Nottingham:

> I had a look at this. I think we can fix things for private -- proposal is to change:
> ... 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).


> However, the semantics of these arguments on no-cache is much less
> clear. IME this isn't implemented, so I'd suggest deprecating it by
> changing:

qualified no-cache == qualified private, except that private only
applies to shared caches.

>       If the no-cache response directive specifies one or more field-
>       names, this requirement is limited to the field-values associated
>       with the listed response header fields.  That is, a cache MUST NOT
>       send the specified field-name(s) in the response to a subsequent
>       request without successful validation on the origin server.  This
>       allows an origin server to prevent the re-use of certain header
>       fields in a response, while still allowing caching of the rest of
>       the response.
>       Note: Most HTTP/1.0 caches will not recognize or obey this
>       directive.  Also, no-cache response directives with field-names
>       are often handled by implementations as if an unqualified no-cache
>       directive was received; i.e., the special handling for the
>       qualified form is not widely implemented.

I don't see a need for bloating the specification with this note. It do
not add any value, only confusion.

> To:
> """
> The no-cache response directive was originally defined to allow
> specification of one or more field-names as a parameter value.
> However, this form is not widely implemented, and their semantics are
> not well-defined; as a result, this form is deprecated, and servers
> SHOULD NOT send them. Caches are advised to silently ignore these
> parameters and treat the response as if it had contained a bare
> no-cache directive.
> """


The original text for no-cache is fine imho.

> Comments? I'm not against also deprecating them in this fashion on
> private, if there's support for that.


Cache-Control: private=Set-Cookie

makes a whole lot sense to support, and I see no reason why to deprecate

Received on Friday, 17 February 2012 01:42:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC