- From: Adrien de Croy <adrien@qbik.com>
- Date: Wed, 27 May 2009 05:17:26 +1200
- To: HTTP Working Group <ietf-http-wg@w3.org>
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