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

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).

Ok.

> 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.
> """

Why?

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.

Why?

Cache-Control: private=Set-Cookie

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

Regards
Henrik

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