SPOOF issue (Was: Re: Rewrite of 13.12 (Cache keys))

Roy T. Fielding:
>
[...]
>
>For reasons of security, completeness, simplicity, and transparency,
>the cache cannot serve a response received using one Request-URI to
>a client requesting some other Request-URI,  even when such would be
>indicated by transparent negotiation.  Simply obeying that principle
>removes most of the complexity that Koen is talking about.

I think a mechanism by which the response for URI 1 influences what is
cached for URI 2 is needed in the long run, to optimize caching for
transparent negotiation.  But I have argued strongly, in yesterday's
phone conference, against the inclusion in the plain 1.1 spec of such
a mechanism.

Some people in the phone conference yesterday wanted such a mechanism,
though they did not explain, as far as I could tell, why they wanted
it, let alone why they wanted it in plain 1.1.  This mechanism is
certainly not needed as a content negotiation `hook'.

I see I'm the issue owner for spoofing, so I'll now make an official
statement:

 There is _no consensus_ in the WG now, and there will likely be no
 consensus in the next few weeks, about the need to include, into
 plain 1.1, a mechanism by which the response for URI 1 can change or
 create data cached for URI 2.

 According to the guidelines for deciding what is in 1.1, this means
 that such a mechanism must _not_ be in the 1.1 document, and that the
 SPOOF issue should be labeled as (not 1.1).

 Consensus may appear, soon, about a mechanism by which the response
 for URI 1 can _make stale_ the data cached for URI 2.

This official statement is not just based on Roy and me being opposed
to such a mechanism in 1.1 today, but also on my knowledge that other
members of the wg, who are not in the editorial group, have objected
to such mechanisms in the past, or have stated that anti-spoofing
rules will need careful consideration.

I strongly urge the people who want a spoofing mechanism in plain 1.1
to supply to the WG reasons for having it.  If I hear nothing in the
next few days, I will close the SPOOF issue.

> ...Roy T. Fielding

Koen.

Received on Saturday, 27 April 1996 16:00:29 UTC