Re: list of pending proposals

Shel Kaphan writes:
> Balint Nagy Endre writes:
> 
>  In this case, we can define the sanity check as:
>  > URI given in a Location header field value and the request-URL
>  > must have common prefix
> 	...
>  > Adding this restriction to location-URI excludes the forgery problem,
>  > but may have unvanted side effects.
> 
> Some sanity similar to what mention seems reasonable -- but it is safe to
> allow such sanity checks to be optional, as the worst thing that could
> happen is for a page to be removed from a cache prematurely. So the
> sanity checks don't need to be defined as part of the protocol.
I wrote on checks, because I suppose the information in Location and URI
headers can be used for more than cache entry invalidation.
There we have two options:
a) add a few words to the spec on checks needed on the server side
for Location and URI headers supplied by users
b) add some restrictions into the spec about Location and URI headers
and we have of course a do nothing option, but that seems to me a non-option.
The a) variant puts the responsibility of correctness of the Location and
URI headers to the origin servers, while the b) variant restricts the
hole useable for forgeries to a narrow domain.
> 	...

On server-control:
I reconsidered the whole problem. Now I think, that extensibily targeted
by server-control (including permissive cache-control) should be treated as
a server implementation issue instead of a protocol design issue.

On security issues:
Fully agree with you.

On the story blaming Microsoft:
I don't know whether Microsoft did something wrong or not.
I haven't heard yet that somebody sniffed the conversation between MSN and
the WIN95 beta installation program, and I think Microsoft did exactly
what their spokesperson said: an electronical version of their conventional
registration card. I presume Microsoft innocent until the opposite is proven
- though I am not a Microsoft-lover.

>  > >  > > 8a.  corollary: request methods should NOT be used as part of the
>  > >  > > cache key for returned entities.  The reason: multiple entries under
>  > >  > > the same URI contribute to the "evil doppelganger" problem.  (Among
>  > >  > > standard HTTP methods, only GET and HEAD could ever fetch the cached
>  > >  > > results of other method requests).  Cacheability of returned results
>  > >  > > is entirely controlled by metadata in headers.
>  > >  > Sanity checks again.
>  > > What sanity checks do you mean? This proposal is actually a
>  > > proposal in the direction of making things more CONSERVATIVE.
>  > > An even more conservative approach would be that only GET can cache its
>  > > results and use those results later, but I don't like that.
>  > If we have enough good sanity check, we don't need this restriction.
>  > Not having sanity checks, this restriction *may* be a MUST.
>  > > 	...
> 
> I don't think so, because it appears to be a common practice to do it as
> I suggest already. (I know this from experiments on different browsers
> and online systems, not from seeing the code).  I'd just like to make
> this explicit.
I don't think that we should restrict the design of the protocol this way.
The necessity of sanity checks regarding this (8a) ceases if we can agree
on server-control as an implementation issue.
The PLAY method - given in my prevous example - would return ST2 connection
setup information in the entity-body, while GET method - applied to the same
PLAY-able URI - would return the file to be PLAY-ed.

The situation is similar in my second example:
Somebody may decide that directory listings of the current
implementations aren't pretty enough, and play around with
a DIR method, which returns some easy-to-parse directory
listing format.
(DIR capable clients then may display this information in
configurable and nice way.)
In this case we will have two formats for (nearly) the same
information. These two formats will be mutually unusable for
the other method, while they are independently cacheable, and
sometimes even convertable.
This imaginary experiment can be repeated with GET and a DIR-format:
(extension) request header with similar results.

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunt.hu>

Received on Saturday, 23 September 1995 07:32:21 UTC