Re: SHOULD-level requirements in p6-caching

In message <90400372-C89F-4E9C-92F6-D8F1A6AAD631@mnot.net>, Mark Nottingham writes:

>In 2.5, 
>
>>    A cache that passes through requests with methods it does not
>>    understand SHOULD invalidate the effective request URI (Section 4.3
>>    of [Part1]).
>
>I'm not sure why this is a SHOULD when all of the other invalidation 
>side effects are MUST-level requirements. Can we raise this to a MUST as 
>well?

First off, what does "not understand" mean here ?

Does that cover a cache which goes "Ohh, POST, I don't do those:
pass it through" ?

Or does it only cover "XYZZY / HTTP/1.1" style requests ?

Second: Are we sure this complies with Principle Of Least Astonishment ?

Third: do we really want to give script kiddies their own private
standards-mandated cache-invalidation button ?

If anything, I would think it should be turned into a MUST NOT
requirement, reasoning that if you use privately defined requests,
you'd better think carefully about how that should work with client
side caches in the first place.


>In 3.2.1 (only-if-cached),
>
>>       If it receives this
>>       directive, a cache SHOULD either respond using a stored response
>>       that is consistent with the other constraints of the request, or
>>       respond with a 504 (Gateway Timeout) status code.
>
>MUST?

I must confess I have never understood this directive, nor been able to
come up with a non-hostile intent for using it.  Can anybody enlighten me ?

Nit:
	"The only-if-cached request directive indicates that the client
	only wishes to return a stored response."

	s/return/receive/ ?

>In 3.3,
>
>>    A server SHOULD NOT send Expires dates more than one year in the
>>    future.
>
>Prose.

Why this policy restriction ?

Remove entirely ?

>In 3.4,
>
>>    When the no-cache directive is present in a request message, a cache
>>    SHOULD forward the request toward the origin server even if it has a
>>    stored copy of what is being requested.
>
>Prose.

Have you discussed the future of "Pragma:" before ?

I would like to see the text say that if there is a "Cache-Control:"
header "Pragma:" MUST be ignored, to resolve the possible conflicts
between them.

>In 3.5,
>
>>    A server SHOULD include a Vary header field with any cacheable
>>    response that is subject to server-driven negotiation.
>
>I can't decide if this needs to be a requirement; if it does, I think it 
>should be a MUST; if not, it should be prose. Thoughts?

This one is a nasty one.

Vary is a very crude mechanism in todays web, where objects are
customized to specific (browser, platform, extension) triplets.

For instance Varnish experience is that "Vary: User-Agent" reduces
cache hit rate by about two orders of magnitude.

Some sites "solve" this problem using a cookie instead.  However,
you cannot say "Vary: Cookie/my_idea_of_your_browser" to vary only
on a single cookie, so that doesn't really solve the cache problem.

This may be a good case for the geniuine SHOULD:  You really should,
unless you shouldn't because it breaks caching.

Related to this, we should think a moment about Google Analytics
here, since it tends to pollute all objects with Cookies, and "Vary:
Cookie" is implied (but not specified as I recall)

It would be incredibly beneficial for caching, if it were possible
to say "Vary: !Cookie" to indicate that the Cookies are not really
important anyway.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Thursday, 7 April 2011 09:35:58 UTC