draft-ietf-httpbis-p6-cache-06

I've just been working through draft-ietf-httpbis-p6-cache-06, so here 
are a few comments.  all in all it's looking a lot better than the 
sections in 2616

S 2.2 Constructing responses from cache
---------------------------------------
The requirements for whether a stored response may be served require 
that it be (paraphrased)

* matching URI
* compatible method
* Vary used to check selecting request headers.  Presumably no check if 
no Vary (only SHOULD requirement)
* no directives preventing returning from cache
* fresh, allowed to be stale, or validated

This leaves problems if there's no Vary header but content negotiation 
was used.  It's not possible to reliably heuristically determine if 
content-negotiation was used without the Vary header.  Vary is only a 
SHOULD level.  Maybe it should be a MUST level?   There needs to be 
another set of checks, at the minimum that Accept-Encoding matches the 
stored Content-Encoding.  E.g. you can't serve gzip content if there's 
no Accept-Encoding: gzip  Arguably others as well (like Accept-Language 
matching on Content-Language , with q values etc).

It says if there are several stored representations serve the one with 
the most recent Date header (MUST level), but this may not be the 
appropriate one if Vary headers aren't available, and you are say 
selecting based on language.

S 2.5 Request methods that invalidate
-------------------------------------
I don't understand how a URI can be compared to a Content-Location or 
Location header and match yet the host part be different.  Surely to 
match the host part must be the same?  It's not clear to me what's being 
matched with what.

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?


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.

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.


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).  I think it should therefore be explicit that it's not valid 
to mix the directives, else you get a MUST requirement to obey 
nonsensical directives.

Otherwise relax the MUST, or relax it to the extent of nonsensical 
directives.  Also, you can't have a MUST requirement on an extensible 
mechanism.  Extensions need to be optional.

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

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?


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?



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


Thanks

Adrien

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

Received on Tuesday, 26 May 2009 17:14:52 UTC