Re: Last Call: HTTP Extension Framework to Proposed Standard

Roy T. Fielding:
>
>Koen,
>
>The extension framework must not automatically prevent caching.
>There is nothing in Henrik's draft that prevents an extended request
>or response from including the EXISTING cache control mechanisms of
>HTTP/1.1.  It is not necessary, nor is it desired, for the draft to
>assume that an extended message is not cachable just because some
>particular extension might not be cachable.  Therefore, your suggested
>changes are contrary to the design of HTTP.

Roy,

My main concern about caching in the current draft is that some of the
MUST/MAY/SHOULD rules in there (see my comments sent to the IESG) will
sometimes cause the caching directives of upstream servers, which
generated the content, to be violated by downstream caches.  This is
unacceptable to me.

Caching is like security: you should either provide a protocol which is
correct in all cases or you should not provide it alltogether.

This is separate from the issue that some extensions could _want_ to
violate upstream caching directives.  I see no reasons to disallow
this but this use case cannot be used as an excuse for the broken
MUST/MAY/SHOULD rules which apply to all extensions.

The MUST/MAY/SHOULD text in the draft can be fixed, and I am trying to
work on this with Henrik, but I have no idea whether we will
converge.  I do feel that Henrik is not treating the issue with the
care it deserves.

I have other concerns in that the draft is very sketchy and sometimes
misleading in caching advice to implementers, but these are of a lower
order than the glitches in the MUST/MAY/SHOULD discipline.

Koen.

Received on Thursday, 18 February 1999 05:37:26 UTC