Re: #290 [was: SHOULD-level requirements in p6-caching]

On 04/05/2011, at 8:32 PM, Poul-Henning Kamp wrote:

> In message <79ECC5BD-77F2-4C36-BEA7-F0F9F1652058@mnot.net>, Mark Nottingham wri
> tes:
> 
>> Is your use case that you want to be able to send requests that 
>> CC-unaware HTTP/1.0 caches will pass through, and yet allow them to be 
>> pulled from cache by a CC-aware implementation?
> 
> My "use case" is simply that if they are in conflict, we should give
> very clear guidance on how that should be resolved, we currently do
> not do that.

OK. As I said, we already have text -- from 2616 -- that explicitly makes Pragma: no-cache equivalent to CC: no-cache in requests. 

Then, p6 2.2 says:

>    For a presented request, a cache MUST NOT return a stored response,
>    unless:
[...]
>    o  the presented request and stored response are free from directives
>       that would prevent its use (see Section 3.2 and Section 3.4)


That's IMO pretty clearly stated (those references are to the sections defining Cache-Control and Pragma, respectively). From here, I can see three possible directions:

1) We could perhaps refine "would prevent its use" here to be more specific; if that's what you're interested in, please say so and we'll pursue that.

2) We could add more text (e.g., in 2.3 Freshness Model) that says that when CC: no-cache and/or Pragma: no-cache are present, the freshness model isn't in use, but we'd be saying the same thing in another way.

On that line, one of the reasons that the original RFC2616 part 13 was so difficult to use was that it said many things twice, and sometimes three times. When I did the initial edit of p6, I was able to remove ten *pages* of such redundant text, and the overwhelming feedback we've had so far is that this has made the specification much clearer, readable and useful. 

So, I'm reluctant to repeat requirements, because we have good reason to believe that it makes the spec worse, not better.

3) OTOH if you're really arguing that we need to change this so that CC's presence signals that Pragma isn't to be followed (your original suggestion, which is why I was asking about use cases), that's a totally different discussion. I've outlined the reasons why I think that won't work; other implementers may have opinions too.


> Further I think it makes sense if this guidance helps eliminate Pragma
> in the long run.


Well, I think we're there, as much as we can be; we deprecate the header for new uses. 

The argument behind the current design, AIUI, is that we can't completely get rid of it, because there might be a HTTP/1.0 cache that doesn't understand CC: no-cache in requests. One could say that such caches don't really exist any more (and I'd probably buy it, not sure about how others would feel), but I don't see how making the change you propose helps get rid of the header.

Cheers,

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

Received on Wednesday, 4 May 2011 10:51:32 UTC