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

Mark - thanks for your comments, I've a few more below

Mark Nottingham wrote:
> 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.
>
>
so when the language mentions invalidation of a cache entry, it doesn't 
necessarily mean deletion from the cache, purely flagging it as 
requiring revalidation?

>> 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>.
>
Further reading on the Content-Location header helped quite a lot in the 
end.

>
>> 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 definitely think the HTTPbis docs are a lot easier to read.


>
>> 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?
>
my reading is that a private with headers is more like a public, since 
it means only those headers are private.  So to treat it as private 
whilst being safe (in that it won't cache any part of the resource), 
won't also be optimal in terms of cache efficiency.


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

thanks.

Adrien

> Cheers,
>
>
> -- 
> Mark Nottingham     http://www.mnot.net/
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Wednesday, 3 June 2009 00:48:59 UTC