Re: draft-ietf-httpbis-p6-cache-06

Hi Adrien,

Thanks for the feedback. I think others have covered most of this, but  
see below for a few responses...

On 27/05/2009, at 3:17 AM, Adrien de Croy wrote:
> Wrt POST (or any method).  If the response to a POST is marked  
> explicitly by the origin server as cachable, why should a subsequent  
> POST invalidate that contrary to other Cache-control directives?   
> Surely this should only apply if the original method was not POST?

Because POST changes state on the server; it's a useful pattern to  
have POST (or other responses) cached, but invalidated upon a visible  
update.


> S 2.6 Caching Negotiated responses
> ----------------------------------
> Should I then be referring to Section 4.1 of [part3] to resolve the  
> issues around content negotiation?  If so, maybe a mention in S 2.2  
> would be useful.

Well, 2.2 refers to 2.6 for a full treatment, which then refers to 4.1  
of p3.


> I also don't understand in para 5 the sentence "If the server  
> responds with 304 (Not Modified) and includes an entity tag or  
> Content-Location that indicates the entity to be used"  How can  
> Content-Location be used to select an entity?  Do you match on  
> previously returned Content-Location headers for requests for the  
> same URI?  Is that what the final para is getting at?  Maybe the  
> wording could be a bit clearer.

Interesting question; not sure if this is implemented anywhere.  
Recording this as issue #167 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/167 
 >.


> S 3.2 Cache-Control
> -------------------
> first sentence states that directives MUST be obeyed.   This doesn't  
> fit with a strategy of ignoring unhandled directives if you get a  
> mixture of request and response directives in a message (which is  
> still allowed in the ABNF).

As discussed, this could use some tweaking. #168 (editorial); <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/168 
 >


> Some cache control directives are confusingly similar, especially  
> for response directives.

Yes. There's not a lot we can do about this except improve the doc  
(which we've tried to do in this revision; compare to 2616, which IMO  
was even more confusing). #168 should incrementally improve this (in a  
small way).


> I can't see anywhere easily where it says what to do in some cases  
> either.
> 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?
>
> 2. 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?

Good question. My experience is that this isn't implemented, and that  
caches just ignore the extensions and treat them as bare private and  
no-cache, respectively. Anybody else?

Even if they aren't widely implemented, it seems like they're not  
harmful as defined (since caches take a more drastic but still  
conformant step). However, we can consider deprecating this behaviour.

Now issue #169 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/169>.


> S 3.4 Pragma. -------------
> The BNF for this mentions extension-pragma.  Were there ever any of  
> these?  Does it make sense to continue to support an extension  
> mechanism on a deprecated header that no-one extended?

IIRC there are a few floating out there, so we need to allow them  
syntactically, at least.


> I've also seen some responses lately that have multiple Cache- 
> Control headers - is this valid?

You mean something like

Cache-Control: max-age=60
Cache-Control: public

?

If so, yes, that's completely allowed; p1 talks about headers being  
allowed to be serialised in different forms.

Cheers,


--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 2 June 2009 05:47:11 UTC